Re: [v6ops] FW: New Version Notification for draft-palet-v6ops-rfc7084-bis-00.txt

[Tore Anderson <[e-mail]>]

Hi Jordi,

* JORDI PALET MARTINEZ <[e-mail]>

> So, just to summarize, in RFC7084, 6rd and DS-LITE are considered as
> SHOULD.
> 
> In my version:
> 
> 1) Considering that there’re no more IPv4 addresses and according to
> my experience with service providers, they will prefer to avoid dual
> stack in the WAN ASAP, and avoid CGN, I think 6rd and DS-LITE need to
> be changed to MAY.
> 
> 2) At the same time, I’ve included lw4o6, also with MAY. The
> rationale for this: Many service providers try to avoid the CGN, and
> lw4o6 is a way to do so, without increasing the cost of the CE.
> Basically, a CE that supports a regular IPv4 NAT+DS-Lite, is already
> capable of supporting lw4o6. The cost in terms of CE flash memory for
> DS-Lite is about 1Kb. The open source package available for DS-Lite
> that I’ve been digging-in takes 6Kb, but already includes also
> support for both MAP versions.
> 
> 3) Include support for 464XLAT, MAP-E, MAP-T as SHOULD. Those
> protocols are the 3 alternatives that a service provider has to
> deploy IPv6-only WAN, but at the same time provide dual-stack in the
> LANs, with practically the same functionalities or even more, that
> what CGN requires. At the service provider network, it requires,
> instead of CGN, a stateful NAT64 (which cellular providers are
> already using) or a Border Relay (for MAP). Basically, a CE needs
> only 3Kbytes of code in the flash to support CLAT (the CE part of
> 464XLAT). The support for MAP (both versions and also lw6o4),
> requires about 6Kb.
> 
> 4) Include support for 6in4 as SHOULD. The rational for this:
> According to my experience, sometimes, business customers (specially
> SMEs) are in the same access network as residential ones, but they
> are provisioned manually and often require dual-stack with public
> IPv4 addresses, because they have to publish external services such
> as VPNs, or others that may not yet rely in an IPv6-only network.
> I’ve seen cases of service providers with 10.000 customers and 250 of
> those “SMEs”, and all them are provisioned manually because don’t
> make sense to find an automatic configuration. So, I think we must
> keep this support, with typically is already available in any
> dual-stack router today. In fact, if the router supports 6to4 or 6rd,
> the 6in4 support is already there. In terms of flash utilization,
> 6in4 requires 1Kb, 6rd 2Kb and 6to4 1Kb.
> 
> So, the questions for the WG:
> 
> Do you agree with my changes 1, 2, 3 and 4 above?

I believe this document should not attempt to rank between IPv6
transition technologies. If you say that transition tech Foo is SHOULD
while Bar is MAY you're suggesting that Foo is somehow better or more
relevant than Bar.

The actual ranking of such a list does however depend entirely on the
deployment models of the ISPs operating in the market the device is
being targeted at. There's no universal ranking here, no single
technology that has «won» yet.

So if you really need to make this «IPv6 CE router» document almost as
much about IPv4 as it is about IPv6 by listing all the available
transition technologies, the they should all be MAY.

Better yet, move them from the normative section into the appendix or a
separate document analysing and comparing all the various transition
technolgies.

> Now a more complex question. Do you think it will be acceptable for 3
> and may be 4 above, to be a MUST instead of just SHOULD?

Absolutely not.

Tore