Subject: Re: [sunset4] Meeting in BA

From: Naoki Matsuhira <[email-masked]>
Date: Fri, 12 Feb 2016 10:51:51 +0900

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

(2016/01/20 0:05), George, Wes wrote:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sunset4

---

From: "George, Wes" <[email-masked]>
Date: Mon, 15 Feb 2016 18:52:11 +0000

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

>> Anything below this line has been added by my company’s mail server, I

________________________________

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.

---

From: Naoki Matsuhira <[email-masked]>
Date: Tue, 16 Feb 2016 19:05:06 +0900

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

---

From: "George, Wes" <[email-masked]>
Date: Tue, 16 Feb 2016 18:41:58 +0000

Below inline with WG]

>corporate network, so I believe transition technology should support
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.

>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)

>network such as for backbone network, enterprise network, datacenter
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.

>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.

>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

---

From: Naoki Matsuhira <[email-masked]>
Date: Thu, 18 Feb 2016 15:04:15 +0900

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.

(2016/02/17 3:41), George, Wes wrote:
> Below inline with WG]
> 
> On 2/16/16, 5:05 AM, "Naoki Matsuhira"<[email-masked]>  wrote:
> 

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.

> similar to the VPNv4 address used in RFC4364, which is why I mentioned 4PE

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

---

From: [email-masked]
Date: Thu, 18 Feb 2016 11:55:12 +0100

Naoki,

MAP et al already supports:
 - private IPv4 addresses
 - full IPv4 address or IPv4 prefix (i.e. does not need NAT44 on the CE)
 - does mesh mode

I'm not quite sure I understand what's left of the problem space to solve.

Best regards,
Ole

> On 18 Feb 2016, at 07:04, Naoki Matsuhira <[email-masked]> wrote:
> 
> Wes,
>

---

From: "George, Wes" <[email-masked]>
Date: Thu, 18 Feb 2016 18:00:06 +0000

>statement must require before next Buenos Aires meeting ?  or continue
WG] it's always helpful to have a problem statement in a draft so that
people who build a list of drafts to review prior to the meeting can
review it ahead of time, but if you need to spend some time discussing it
on the list to flesh it out, that's certainly fine. Either way, you need a
clear problem statement and explanation of why your solution is necessary
or uniquely suited to solving your problem compared with other options
before the WG will be able to give you useful feedback at a meeting.

>so I think GRE and IPv4 in IPv6 tunnel are the
WG] Perhaps, but there are methods to reduce that mesh requirement through
the use of hub and spoke topologies. Indeed in the case of GRE, it's
possible to run routing protocols over those tunnels to make the network
look like a contiguously connected IPv4 network. In fact, this is exactly
what we did in the early days of the 6bone - we tunneled IPv6, BGP, and
ISIS over GRE in IPv4 to build an interconnected IPv6 "backbone" network
out of islands of IPv6-capable routers with IPv4-only connectivity between
them. Tunneling like this has a lot of limitations, but N^2 configuration
isn't necessarily one of them.

I think you have some work ahead of you to convince people that
interconnecting islands of legacy IPv4-only devices is best solved by
encapsulating it over IPv6 (regardless of the encap/decap mechanism)
rather than leaving the interconnecting network dual-stack until those
legacy devices can be eliminated. If leaving the network dual-stack is
impossible, I argue that the cleaner solution is using ALGs to translate
to IPv6 as close to those those legacy IPv4-only devices as possible so
that they can talk to the rest of the modern network and vice versa
without requiring large portions of the network to remain IPv4-capable
(and encapsulated over an IPv6-only backbone). The general goal in
sunset4, and I think in IETF in general, is to focus on IPv6 transition
technologies that increase deployment of IPv6 and enable network operators
to shrink or eliminate their dependence on IPv4. The end state is an
IPv6-only network, and things that indefinitely prolong the life of IPv4
and devices that require it, even if it's only in certain islands of the
network, don't provide much progress toward that end state.

Wes

---

From: Naoki Matsuhira <[email-masked]>
Date: Fri, 19 Feb 2016 08:54:02 +0900

Ole,

Is RFC7597 is corrent document to understand your comments ?

I know MAP-E and MAP-T. Does MAP means both MAP-E and MAP-T?

regards,

Naoki

(2016/02/18 19:55), [email-masked] wrote:
>> On 18 Feb 2016, at 07:04, Naoki Matsuhira<[email-masked]>  wrote:
>>
>> Wes,
>>

---

From: [email-masked]
Date: Fri, 19 Feb 2016 22:23:34 +0100

Naoki,

> I know MAP-E and MAP-T. Does MAP means both MAP-E and MAP-T?

yes, 7597 is a good starting point. MAP refers to both. And you can include LW46 (RFC7596) if you like.

Best regards,
Ole

---

From: Naoki Matsuhira <[email-masked]>
Date: Sat, 20 Feb 2016 14:30:21 +0900

Ole

Thanks.

Naoki