Discussion:
[sunset4] Meeting in BA
George, Wes
2016-01-19 15:05:18 UTC
Permalink
Hello -

WG scheduling cutoff is 19 February. That gives us almost exactly a month. The list has been very quiet, and we need to see some activity to justify a meeting – what does the WG wish to discuss face to face?

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Naoki Matsuhira
2016-02-12 01:51:51 UTC
Permalink
Hi,

Recently, I submitted six drafts. I want to ask sunset4 WG there are
interests in these drafts.

The basic idea is IPv4 mapped IPv6 address which could distinguish
several IPv4 network including IPv4 private network with IPv4 private
address (M46A).

I am proposing encapsulation technologies using this address (M46E-FP,
M46E-PR, M46E-PT) , and translation technology using this address(M46T).
I am also proposing IPv4 address sharing technology(M4P6E).

I thing there are proposal both sunset4 WG have interest and not interest.

I especially would like to propose the encapsulation technologies. These
technologies are IPv4 over IPv6 encapsulation, so by using these
technologies, it is possible sunsetting IPv4 (IPv6 only )in network
infrastructure, and provide IPv4 with overlay. I believe with this
technology, could provide IPv4 as a service. That may first step to
completely sunsetting IPv4, with staring focus to infrastructure.

These six drafts are the following.

https://www.ietf.org/id/draft-matsuhira-m46a-00.txt
https://www.ietf.org/id/draft-matsuhira-m46e-fp-00.txt
https://www.ietf.org/id/draft-matsuhira-m46e-pr-00.txt
https://www.ietf.org/id/draft-matsuhira-m46e-pt-00.txt
https://www.ietf.org/id/draft-matsuhira-m46t-00.txt
https://www.ietf.org/id/draft-matsuhira-m4p6e-00.txt

In addition, these proposal had been proposed under the name SA46T in
the past. Starting proposal, there was only one idea, however I got
several ideas. So I organize and changing name, and re-submitted. If you
know SA46T, I believe you will understand immediately.

Regards

Naoki Matsuhira
Post by George, Wes
Hello -
WG scheduling cutoff is 19 February. That gives us almost exactly a
month. The list has been very quiet, and we need to see some activity to
justify a meeting – what does the WG wish to discuss face to face?
Thanks,
Wes
Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------
------------------------------------------------------------------------
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject
to copyright belonging to Time Warner Cable. This E-mail is intended
solely for the use of the individual or entity to which it is addressed.
If you are not the intended recipient of this E-mail, you are hereby
notified that any dissemination, distribution, copying, or action taken
in relation to the contents of and attachments to this E-mail is
strictly prohibited and may be unlawful. If you have received this
E-mail in error, please notify the sender immediately and permanently
delete the original and any copy of this E-mail and any printout.
_______________________________________________
sunset4 mailing list
https://www.ietf.org/mailman/listinfo/sunset4
George, Wes
2016-02-15 18:52:11 UTC
Permalink
Let's start the discussion here -

Can you explain how this is different from existing IPv4 over IPv6
transition technologies e.g. MAP, DSLite, 464XLat?
IETF doesn't have a lot of appetite for defining yet another transition
technology, even those that use IPv6 to provide IPv4 as a service, so you
have an uphill battle to demonstrate why this is something we should work
on. What problems exist with the already defined and implemented protocols
listed above that this solves, and how? This is probably something that
should go in your intro draft, but you can start by writing something up
on the mailing list for discussion.

Thanks,

Wes
Post by Naoki Matsuhira
Hi,
Recently, I submitted six drafts. I want to ask sunset4 WG there are
interests in these drafts.
The basic idea is IPv4 mapped IPv6 address which could distinguish
several IPv4 network including IPv4 private network with IPv4 private
address (M46A).
I am proposing encapsulation technologies using this address (M46E-FP,
M46E-PR, M46E-PT) , and translation technology using this address(M46T).
I am also proposing IPv4 address sharing technology(M4P6E).
I thing there are proposal both sunset4 WG have interest and not interest.
I especially would like to propose the encapsulation technologies. These
technologies are IPv4 over IPv6 encapsulation, so by using these
technologies, it is possible sunsetting IPv4 (IPv6 only )in network
infrastructure, and provide IPv4 with overlay. I believe with this
technology, could provide IPv4 as a service. That may first step to
completely sunsetting IPv4, with staring focus to infrastructure.
These six drafts are the following.
https://www.ietf.org/id/draft-matsuhira-m46a-00.txt
https://www.ietf.org/id/draft-matsuhira-m46e-fp-00.txt
https://www.ietf.org/id/draft-matsuhira-m46e-pr-00.txt
https://www.ietf.org/id/draft-matsuhira-m46e-pt-00.txt
https://www.ietf.org/id/draft-matsuhira-m46t-00.txt
https://www.ietf.org/id/draft-matsuhira-m4p6e-00.txt
In addition, these proposal had been proposed under the name SA46T in
the past. Starting proposal, there was only one idea, however I got
several ideas. So I organize and changing name, and re-submitted. If you
know SA46T, I believe you will understand immediately.
Regards
Naoki Matsuhira
Post by George, Wes
Hello -
WG scheduling cutoff is 19 February. That gives us almost exactly a
month. The list has been very quiet, and we need to see some activity to
justify a meeting – what does the WG wish to discuss face to face?
Thanks,
Wes
Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------
------------------------------------------------------------------------
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject
to copyright belonging to Time Warner Cable. This E-mail is intended
solely for the use of the individual or entity to which it is addressed.
If you are not the intended recipient of this E-mail, you are hereby
notified that any dissemination, distribution, copying, or action taken
in relation to the contents of and attachments to this E-mail is
strictly prohibited and may be unlawful. If you have received this
E-mail in error, please notify the sender immediately and permanently
delete the original and any copy of this E-mail and any printout.
_______________________________________________
sunset4 mailing list
https://www.ietf.org/mailman/listinfo/sunset4
________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Naoki Matsuhira
2016-02-16 10:05:06 UTC
Permalink
Thank you, Wes,

The essence of my proposal is thinking including private network with
IPv4 private address. There are many many private network such as
corporate network, so I believe transition technology should support
IPv4 private address.

We know that IPv6 is beginning to spread, in the near feature, the
situation with wide IPv6 and small IPv4 and small but many IPv4 private
will be the reality. Looking that time, IPv6 should wind up IPv4 network
including private address, then enable IPv6 only operation in
infrastructure, and provide IPv4 continuous use environment as a service.

The technical essence of my proposal is Plane ID in M46A. And I propose
my proposal as a general-purpose technology, and may apply many IPv4
network such as for backbone network, enterprise network, datacenter
network.

The difference from MAP, DSLite, 464XLat, I understand these are
combined technology, i.e., NAT with hub and spoke Tunnel. In M46E
(encapsulation) position, M46E and NAT combination may possible. I
believe the decision of such combination is focusing to access network
and main point is address sharing.

As encapsulation technology, M46E support full mesh, and N point full
mesh normally require N^2 configuration, however M46E-FP require N
configuration. So I believe these proposal may contribute.

Regards,

Naoki
Post by George, Wes
Let's start the discussion here -
Can you explain how this is different from existing IPv4 over IPv6
transition technologies e.g. MAP, DSLite, 464XLat?
IETF doesn't have a lot of appetite for defining yet another transition
technology, even those that use IPv6 to provide IPv4 as a service, so you
have an uphill battle to demonstrate why this is something we should work
on. What problems exist with the already defined and implemented protocols
listed above that this solves, and how? This is probably something that
should go in your intro draft, but you can start by writing something up
on the mailing list for discussion.
Thanks,
Wes
Post by Naoki Matsuhira
Hi,
Recently, I submitted six drafts. I want to ask sunset4 WG there are
interests in these drafts.
The basic idea is IPv4 mapped IPv6 address which could distinguish
several IPv4 network including IPv4 private network with IPv4 private
address (M46A).
I am proposing encapsulation technologies using this address (M46E-FP,
M46E-PR, M46E-PT) , and translation technology using this address(M46T).
I am also proposing IPv4 address sharing technology(M4P6E).
I thing there are proposal both sunset4 WG have interest and not interest.
I especially would like to propose the encapsulation technologies. These
technologies are IPv4 over IPv6 encapsulation, so by using these
technologies, it is possible sunsetting IPv4 (IPv6 only )in network
infrastructure, and provide IPv4 with overlay. I believe with this
technology, could provide IPv4 as a service. That may first step to
completely sunsetting IPv4, with staring focus to infrastructure.
These six drafts are the following.
https://www.ietf.org/id/draft-matsuhira-m46a-00.txt
https://www.ietf.org/id/draft-matsuhira-m46e-fp-00.txt
https://www.ietf.org/id/draft-matsuhira-m46e-pr-00.txt
https://www.ietf.org/id/draft-matsuhira-m46e-pt-00.txt
https://www.ietf.org/id/draft-matsuhira-m46t-00.txt
https://www.ietf.org/id/draft-matsuhira-m4p6e-00.txt
In addition, these proposal had been proposed under the name SA46T in
the past. Starting proposal, there was only one idea, however I got
several ideas. So I organize and changing name, and re-submitted. If you
know SA46T, I believe you will understand immediately.
Regards
Naoki Matsuhira
Post by George, Wes
Hello -
WG scheduling cutoff is 19 February. That gives us almost exactly a
month. The list has been very quiet, and we need to see some activity to
justify a meeting – what does the WG wish to discuss face to face?
Thanks,
Wes
Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------
------------------------------------------------------------------------
This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject
to copyright belonging to Time Warner Cable. This E-mail is intended
solely for the use of the individual or entity to which it is addressed.
If you are not the intended recipient of this E-mail, you are hereby
notified that any dissemination, distribution, copying, or action taken
in relation to the contents of and attachments to this E-mail is
strictly prohibited and may be unlawful. If you have received this
E-mail in error, please notify the sender immediately and permanently
delete the original and any copy of this E-mail and any printout.
_______________________________________________
sunset4 mailing list
https://www.ietf.org/mailman/listinfo/sunset4
________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
George, Wes
2016-02-16 18:41:58 UTC
Permalink
Below inline with WG]
Post by Naoki Matsuhira
The essence of my proposal is thinking including private network with
IPv4 private address. There are many many private network such as
corporate network, so I believe transition technology should support
IPv4 private address.
WG] you seem to be asserting that other transition technologies do not
support private addresses, but I don't think that this is accurate. The
way I see this, there are two transition possibilities here:
1) legacy devices/networks that must continue using IPv4 because it is
impossible/cost prohibitive to add IPv6 support
2) devices and networks that are using private IPv4 today because of
insufficient availability of globally unique IPv4, which can be enabled
for IPv6 (either dual-stack or single stack) as appropriate.

The model for this is not to find ways to prolong the existence of
IPv4-only networks, even if they're private addresses. If the situation
looks like #1, then the network works as-is today, so it can either be
shrink-wrapped at its current size, or if it needs to grow, you can put an
ALG or NAT64 gateway in front of the legacy devices so that they can reach
and be reached by IPv6-only devices. If the situation looks like #2, IPv6
is deployed, and the dependence on private IPv4 gradually falls away as
more services migrate to use IPv6. If this does not cover what you're
describing, please be much more specific about the problem you're solving
that the others do not.
Post by Naoki Matsuhira
We know that IPv6 is beginning to spread, in the near feature, the
situation with wide IPv6 and small IPv4 and small but many IPv4 private
will be the reality. Looking that time, IPv6 should wind up IPv4 network
including private address, then enable IPv6 only operation in
infrastructure, and provide IPv4 continuous use environment as a service.
WG] it's not totally clear from the above, but it sounds like you're
proposing a method to connect IPv4-only islands over an IPv6-only network.
There are multiple existing solutions for this, including GRE or IPv4 in
IPv6 tunnels, MPLS encapsulation (L2/L3 VPNs), etc. The IETF has also
identified a need for "4PE", which is the IPv4 over IPv6 version of
RFC4798 (6PE) to do these sorts of island connections in a way that
involves less manual provisioning of tunnels. (see RFC 7439 section 3.3.2)
Post by Naoki Matsuhira
The technical essence of my proposal is Plane ID in M46A. And I propose
my proposal as a general-purpose technology, and may apply many IPv4
network such as for backbone network, enterprise network, datacenter
network.
WG] your proposal is very light on details, so it is difficult to evaluate
its applicability. Your mention of plane IDs makes me think that you're
describing a way to disambiguate overlapping private address space,
similar to the VPNv4 address used in RFC4364, which is why I mentioned 4PE
above.
Post by Naoki Matsuhira
The difference from MAP, DSLite, 464XLat, I understand these are
combined technology, i.e., NAT with hub and spoke Tunnel. In M46E
(encapsulation) position, M46E and NAT combination may possible. I
believe the decision of such combination is focusing to access network
and main point is address sharing.
WG] DSLite is a method to encapsulate IPv4 in IPv6. It terminates on a
device that does NAT44, but it could just as easily be bypassed to serve
as a convenient encapsulation mechanism if NAT is not desired. It is
already implemented and supported, making it a more likely solution to
this problem space. If you do not believe that this will be enough, you
need to more clearly articulate your problem and why it cannot be solved
by existing transition technologies.
Post by Naoki Matsuhira
As encapsulation technology, M46E support full mesh, and N point full
mesh normally require N^2 configuration, however M46E-FP require N
configuration. So I believe these proposal may contribute.
WG] possibly, but we need a better sense for when a full mesh of
interconnected IPv4 islands over IPv6 would be required such that this is
something for which we should optimize a solution.

Lastly, I don't think you necessarily need 6 separate drafts for this as
all of them are quite short, so I might suggest reorganizing it down to
one or two larger draft(s) with different sections to discuss the
different variants, and an improved problem statement and gap analysis


Thanks,

Wes


Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------



________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
Naoki Matsuhira
2016-02-18 06:04:15 UTC
Permalink
Wes,

I agree the necessity of problem statement. The draft of problem
statement must require before next Buenos Aires meeting ? or continue
on this mailing list?

I commented in-line below focused only the point that I think.

Thank you your advice that reorganizing to one or two drafts. I have my
own reason why 6 drafts exists, however I would like to think at the
time of future update.
Post by George, Wes
Below inline with WG]
WG] it's not totally clear from the above, but it sounds like you're
proposing a method to connect IPv4-only islands over an IPv6-only network.
There are multiple existing solutions for this, including GRE or IPv4 in
IPv6 tunnels, MPLS encapsulation (L2/L3 VPNs), etc. The IETF has also
identified a need for "4PE", which is the IPv4 over IPv6 version of
RFC4798 (6PE) to do these sorts of island connections in a way that
involves less manual provisioning of tunnels. (see RFC 7439 section 3.3.2)
Basically yes. so I think GRE and IPv4 in IPv6 tunnel are the
comparison. These technology needs N^2 configuration to connect N with
fullmesh. For example, in enterprise network, there are dual stack
backbone and many dual stack stub network, and if backbone dual stack
network operation move to IPv6 only operation, M46E-FP should contribute.
Post by George, Wes
WG] your proposal is very light on details, so it is difficult to evaluate
its applicability. Your mention of plane IDs makes me think that you're
describing a way to disambiguate overlapping private address space,
similar to the VPNv4 address used in RFC4364, which is why I mentioned 4PE
above.
I'm sorry for may poor description capability.
We already have a running code and demonstrate at WIDE camp, Interop
tokyo (3 years) , JGN-plus testbed, Strabed testbed. These technologies
already work. I think draft can more refined on revision.

Thanks,

Naoki

Loading...