Subject: [Softwires] Stateless implementation plan

From: Cameron Byrne <[email-masked]>
Date: Tue, 7 Feb 2012 07:05:42 -0800

Are the map and 4rd solutions deployable for existing networks that do not
have reserves  of ipv4 ?  My assumption is that these solutions target
existing networks that have meaningful growth and they need a v6 solution.

If yes, how? Any pointers within the reams of drafts I should look for?

In my brief and simple skimming, it appears to me that setting up one of
these solutions would require me to collapse my existing network to harvest
back the addresses so that they may be redeployed in map.

What would the deployment process be for an address exhausted network of 10
million subs with 10% annual growth be?

Cb

---

From: Maoke <[email-masked]>
Date: Wed, 8 Feb 2012 00:15:50 +0900

just my personal humble understanding:

basically MAP or 4rd, as it is named, is designed for residual deployment,
i.e., using not-yet-allocated or already-recalled ipv4 addresses for the
ipv4 access of ipv6-enabled networks. its address mapping logic implies
doing the ipv6 address planning as the first step, independent of ipv4.

for the transition of existing ipv4 network without renumbering (or only
renumbering to ipv4-translatable ipv6 addresses), MAP is also applicable
but the operator should pay much attention to the addressing issue. in such
a case, RFC6052/RFC6145 suite is a little better recommended.
- maoke
2012/2/8 Cameron Byrne <[email-masked]>

> What would the deployment process be for an address exhausted network of
> 10 million subs with 10% annual growth be?
>
> Cb
>
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires
>
>

---

From: Rémi Després <[email-masked]>
Date: Tue, 7 Feb 2012 16:28:31 +0100

Le 2012-02-07 à 16:05, Cameron Byrne a écrit :
> Are the map and 4rd solutions deployable for existing networks that do not have reserves  of ipv4 ?  My assumption is that these solutions target existing networks that have meaningful growth and they need a v6 solution.
> 

NAT64 does needs some IPv4 space to work.
MAP/4rd is in the same position, with static sharing instead of dynamic.
> If yes, how? Any pointers within the reams of drafts I should look for?
IMHO, the easiest entry in the stateless work of Softwire is the unified draft (tools.ietf.org/html/draft-despres-softwire-4rd-u-03).

> In my brief and simple skimming, it appears to me that setting up one of these solutions would require me to collapse my existing network to harvest back the addresses so that they may be redeployed in map. 
> 
> What would the deployment process be for an address exhausted network of 10 million subs with 10% annual growth be? 
> 
This has to be looked at compared with NAT64 requirements, with the understanding that a mobile device that supports IPv6 would have most of its traffic in IPv6, and therefore needs only a few IPv4 ports.
(If troubled by not enough IPv4 ports, its ASPs should better become IPv6-enabled.)

RD

---

From: Ole Trøan <[email-masked]>
Date: Tue, 7 Feb 2012 17:02:26 +0100

Cameron,

> If yes, how? Any pointers within the reams of drafts I should look for?

there is a new draft on MAP deployment in the works. should be out any day now.

> In my brief and simple skimming, it appears to me that setting up one of these solutions would require me to collapse my existing network to harvest back the addresses so that they may be redeploye…

it is certainly simpler if you have some available IPv4 address space to start with.
e.g. with a /14 of IPv4 space, you'll get 16 million subs for a sharing ratio of 64. or a /16 with a sharing ratio of 256 .

> What would the deployment process be for an address exhausted network of 10 million subs with 10% annual growth be? 

if you have zero IPv4 addresses left to play with. you can convert a subscriber at a time. then for every subscriber converted, you'd get sharing-ratio-1 IPv4 addresses reclaimed, that you can do the same with.

cheers,
Ole

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Tue, 7 Feb 2012 11:23:37 -0600

Hi Cameron,

Good question. Yes, MAP is deployable even in that case (though the
mileage may vary). One deployment approach suggested below.

What's really interesting is that MAP-T CE function (with sharing
ratio=1, thereby disabling NAT44 on CE) could get us quite comparable to
the CLAT function, and still allowing to use the PLAT device for
stateful NAT64. This flexibility got be highlighted, IMO.

Cheers,
Rajiv

PS: One of many deployment approaches could be to 
	- take one public IPv4 address (or prefix) out of the pool 
	assigned to CGN, and use it in MAP as the starting point
	- exclude that IPv4 address (or prefix) from CGN
	- share that IPv4 address (or prefix) among 2^n subscribers
	using MAP

Needless to say that this would be done on a per PDN GW basis. The above
approach takes quite a simplistic view, suffice to say, and we could
come up with more approaches. I bet that you already thought through
most of this already.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Cameron Byrne
> Sent: Tuesday, February 07, 2012 10:06 AM
> To: [email-masked]
> Subject: [Softwires] Stateless implementation plan
> 
existing
> networks that have meaningful growth and they need a v6 solution.
> 
> In my brief and simple skimming, it appears to me that setting up one
of these
> solutions would require me to collapse my existing network to harvest
back the
> addresses so that they may be redeployed in map.
>

---

From: Tina TSOU <[email-masked]>
Date: Tue, 07 Feb 2012 18:27:14 +0000

Some implementer wrote to me as below. I would like to get some feedback from the WG list before my reply. Thank u.

Hi Tina,
Please clear this doubt of mine:
In the initial stage of IPv6 Migration, there will be vast IPv4 lands connected by IPv6 n/w's, where diff operators must have chosen different transition technology for 6over4 like 6to4,6rd etc. etc.
Now if they have to deploy MAP over this for 4over6 traversal, is MAP always independent of whether 6to4 was used or 6rd used.....because the prefix delegation is different in each.

Sent from my iPad

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 8 Feb 2012 02:36:42 +0000

May I ask a question. Why will people deploy MAP over another tunnel
schema such as 6rd?

On 2/7/12 1:27 PM, "Tina TSOU" <[email-masked]> wrote:

>Now if they have to deploy MAP over this for 4over6 traversal, is MAP
>always independent of whether 6to4 was used or 6rd used.....because the
>prefix delegation is different in each.
>

---

From: "Linjian Song" <[email-masked]>
Date: Wed, 8 Feb 2012 12:11:19 +0800

I guess several scenarios may overlap in one network topology.  MAP and 6rd
functions can be built on a certain edge router？ 

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表
Lee, Yiu
发送时间: 2012年2月8日 10:37
收件人: Tina TSOU; Rajiv Asati (rajiva)
抄送: [email-masked]
主题: Re: [Softwires] Stateless implementation plan

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 8 Feb 2012 04:37:23 +0000

I am ok with that. I guess I was confused by the phase "they have to deploy MAP over this for 4over6 traversal". I assume "this" refers to 6o4 tunneling technique. If somebody wants to implement MAP and 6rd on the same edge router, i don't see any problem. This is similar to implement NAT44 and NAT64 on the same network element.

Cheers,
Yiu

---

From: Rémi Després <[email-masked]>
Date: Wed, 8 Feb 2012 08:16:08 +0100

> May I ask a question. Why will people deploy MAP over another tunnel

6rd can be deployed over Net-10 networks (RFC1918) to deployIPv6.
Shared public IPv4 addresses can then be offered to customers via this IPv6.
Such a use case, based on the header-mappiong variant of 4rd-U rather than on a double MAP encapsulation, is described in tools.ietf.org/html/draft-despres-softwire-4rd-u-03#section-5.4.

RD

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 8 Feb 2012 02:46:04 -0600

Hi Cameron,
4rd solution IMHO is more suitable for a fixed network. CPE in 4rd is
not appropriate to be hosted in a UE.

I think your solution 464XLAT's mobile part is way better for your
purposes. There you can put all your IPv4 resources on the PLAT box so
that CLAT box is kept simpler.

In 4rd, CPEs have A+P and BR is kept "stateless" these are not so
useful for your purposes, I think.

Regards,

Behcet

---

From: Rémi Després <[email-masked]>
Date: Wed, 8 Feb 2012 10:23:27 +0100

Hi Behcet,

> useful for your purposes, I think.

Note however that:
- 464XLAT doesn't support shared IPv4 addresses (while 4rd does)
- 4rd over 6rd can work, and therefore offer both IPv6 and shared-address IPv4 on an RFC1918 network, e.g. on a 3GPP IPv4 PDP (while 464XLAT cannot AFAIK).

Regards,
RD

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 8 Feb 2012 05:04:10 -0600

Hi Remi,

4rd would be quite applicable for some UEs, e.g. mobile routers which
are in charge of a 3G/4G uplink and manage several devices connected
to them such as in vehicles.

Regards,

Behcet

---

From: Rémi Després <[email-masked]>
Date: Wed, 8 Feb 2012 12:12:17 +0100

> to them such as in vehicles.

Yes, I think so.

It remains to:
- finalize 4rd
- find mobile operators that understand the potential
- find mobile-OS vendors that support it
Not necessarily a long path IMHO (but not necessarily a fitness trail either).

Regards 
RD

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 8 Feb 2012 07:20:06 -0500

Indeed. Such a scenario makes little sense to me, given that MAP requires native IPv6 connectivity anyway.

IOW, if CE is able to get native IPv6 anyway for MAP, then anything non-native IPv6 would have no usage.  

Cheers,
Rajiv

Sent from my Phone

---

From: "Lee, Yiu" <[email-masked]>
Date: Wed, 8 Feb 2012 18:36:44 +0000

+1

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 8 Feb 2012 11:49:35 -0800

> - 464XLAT doesn't support shared IPv4 addresses (while 4rd does)

Hmm... we may be getting off topic.

464XLAT definitely shares IPv4 addresses on the PLAT -- That is RFC
6146 -- statefule NAT64.

Perhaps what you mean to say is that 464XLAT uses stateful sharing of
IPv4 addresses as defined in RFC6146.  The public IPv4 address
resources are decoupled from the IPv4 service deployment at the edge.
This is more flexible, IPv4 efficient, and allows for geographic
redundancy of the translation exit points.

So, to summarize.  Both 4RD and 464XLAT support address sharing. One
is stateless and the other is stateful.

> - 4rd over 6rd can work, and therefore offer both IPv6 and shared-address IPv4 on an RFC1918 network, e.g. on a 3GPP IPv4 PDP (while 464XLAT cannot AFAIK).

4RD over 6RD?

That is a lot of RD :)

I believe the implementation report here shows that 464XLAT provides a
good users experience on 3G networks

http://www.ietf.org/mail-archive/web/v6ops/current/msg11906.html

CB

---

From: Rémi Després <[email-masked]>
Date: Thu, 9 Feb 2012 09:40:01 +0100

> 464XLAT definitely shares IPv4 addresses on the PLAT -- That is RFC

Well, if a customer _uses_ 464XLAT, it does get a full IPv4 address (sec 6.1). 
I don't see why a customer that has both an IPv6 prefix (used for more and more of its traffic) and a full public IPv4 address would need needs to use a NAT64.

464XLAT has a DNS proxy in CLATs, which I find a GOOD feature.

Besides that, it ressembles to a subset of some solutions worked on in Softwire, restricted to full IPv4 addresses and to hub and spoke.
Relationship with these other solutions belongs AFAIK to Softwire. 

>> - 4rd over 6rd can work, and therefore offer both IPv6 and shared-address IPv4 on an RFC1918 network, e.g. on a 3GPP IPv4 PDP (while 464XLAT cannot AFAIK).

IPv4 Residual Deployment over IPv6 Rapid Deployment, why not?
It is AFAIK a stateless alternative to PCP in DS-lite.

Regards,
RD