Re: there _is_ IPv6 NAT - just look for it

[Alexandru Petrescu <[e-mail]>]

Le 17/03/2014 03:45, Hesham Soliman a écrit :
>>>>>
>>>>>
>>>>>
>>>>> I agree with this in a sense: IPv6 address space is huge and
>>>>> hence the IPv4 NAT is unnecessary.  IPv6 being embraced in more
>>>>> and more places is a witness of this success.  It solves the IPv4
>>>>> depletion problem in a more Internet way than the architecturally
>>>>> e2e impossible way of NAT IPv4.
>>>>>
>>>>> But, until cellular and some DSL operators provide something
>>>>> shorter than a single /64 to a single SIM end user,
>>>>
>>>> Yes, that is a shocking error in the 3GPP world, but that doesn't
>>>> mean that the IETF should legitimise it.
>>>
>>> => The IETF, represented in the IPv6 (ng) at the time specifically
>>> asked for the /64 to be allocated by 3GPP. This is documented in RFC
>>> 3314.
>>
>> This recommendation seems to not have considered the practical
>> realization of of mobile hotspots.
>>
>> Maybe because in year 2002 when that RFC 3314 was issued there were no
>> cheap smartphones with cellular and wifi interfaces.  Nowadays these are
>> common, and the practical experimentation with them shows its
>> qualifications are less relevant.
>
>
> => If you mean multi-link hot spots (which are still not the norm in any
> way) then it should be straight forward for 3GPP to support DHCP-PD.

I meant any network attached to a cellular using a single SIM and that 
has several /64 subnets.

This is to distinguish it from cases of use of the 64share draft that 
only work with a single such subnet.

And, unless the recommentation for 3GPP to support DHCP-PD materializes 
into deployment the documents per se are of little use, I think.

But I agree with you the 3GPP specs do say DHCP PD.

> don¹t see much for us to do here about that given that the solutions
> already exist. That recommendation was just that at a given time, nothing
> to prevent 3GPP from adapting to changing realities.

Ok.

Alex

>
> Hesham
>
>
>
>>
>> For example, RFC3314 says:
>>> Because multiple IPv6 hosts may attach through a 3GPP handset, the
>>> IPv6 WG recommends that one or more /64 prefixes should be assigned
>>> to each primary PDP context.  This will allow sufficient address
>>> space for a 3GPP-attached node to allocate privacy addresses and/or
>>> route to a multi-link subnet [MULTLINK], and will discourage the use
>>> of NAT within 3GPP-attached devices.
>>
>> This paragraph seems to miss the fact that the privacy addresses are
>> also 64-length IIDs and that multi-link subnets have issues (see the
>> 64share draft).
>>
>> This paragraph discourages the use of IPv6 NAT and offers alternatives
>> which are not valid either.
>>
>> This RFC is also silent about the only real Prefix Delegation (DHCP):
>>> Note that [PREFDEL] cannot be considered stable and has not, at this
>>> stage, been adopted by the IPv6 WG as a WG document.
>>
>> All in all the RFC is no alternative to IPv6 NAT and does not render it
>> unnecessary.
>>
>> Alex
>>
>>>
>>> Hesham
>>>
>>>
>>>>
>>>> Brian
>>>>
>>>>> or alternatively the SLAAC/WiFi changes its EUI-64/64 IID stance,
>>>>> the IPv6 NAT is a viable solution.
>>>>>
>>>>> I consider it seriously when connecting any mobile network to
>>>>> the Internet - like a multi-subnet LAN of a cheap vehicle, or a
>>>>> WPAN, or a fixed sensor network, or a fixed hotspot in a remote
>>>>> area.
>>>>>
>>>>> Alex
>>>>>
>>>>>>
>>>>>> Brian
>>>>>>
>>>>>>>
>>>>>>> Alex
>>>>>>>
>>>>>>>
>>>>>>> But I think that in a lot of scenarios
>>>>>>>> those are advantages, not disadvantages.
>>>>>>>>
>>>>>>>> When people say that IPv6 can't be deployed in ISPs, in
>>>>>>>> enterprise networks, in content providers, in home
>>>>>>>> networks, or in mobile networks because it lacks feature X,
>>>>>>>> we'd do well to remember that there are large deployments
>>>>>>>> of IPv6 in all these areas. I know, because I've personally
>>>>>>>> been involved in all of the above. In my experience,
>>>>>>>> excuses for not deploying IPv6 are, to a great extent, just
>>>>>>>> that: excuses. They have no relationship to the actual
>>>>>>>> reason for not deploying it, which is, and has always been,
>>>>>>>> "we see no benefit" (or, to a lesser extent, "our code
>>>>>>>> doesn't support it", and "our code has bugs" -- both of
>>>>>>>> which are temporary). These excuses mislead the IETF into
>>>>>>>> thinking that the lack of IPv6 deployment means that there
>>>>>>>> is somehow something wrong with the protocol. This in turn
>>>>>>>> causes hand-wringing and standards-writing, but in my
>>>>>>>> experience, that doesn't help: when we remove an excuse,
>>>>>>>> people move on to another excuse -- because the excuse
>>>>>>>> wasn't the real reason anyway.
>>>>>>>>
>>>>>>>> Continued tinkering with IPv6 - especially tinkering with
>>>>>>>> it to make it look more and more like IPv4 in order to
>>>>>>>> reduce imagined "barriers to adoption" - will just erode
>>>>>>>> IPv6's long-term advantages by eliminating the
>>>>>>>> simplification, robustness, and benefits that IPv6 as it is
>>>>>>>> today *does* provide -- and it won't lead to adoption
>>>>>>>> anyway, because lack of adoption is not a technical issue.
>>>>>>>>
>>>>>>>> What we need to do now is stick to the protocols as
>>>>>>>> designed and wait until the combination of ever-increasing
>>>>>>>> pain caused by IPv4 exhaustion, and
>>>>>>>> exponentially-increasing IPv6 deployment in the Internet at
>>>>>>>> large (or at least in the consumer space), change the
>>>>>>>> "there's no benefit" equation. That *does* have the power
>>>>>>>> to cause deployment in a way which changing the standards
>>>>>>>> will never have -- and as you put it, the more we change
>>>>>>>> now, the more we *delay* deployment, by causing vendors to
>>>>>>>> write code that then needs to be waited for, tested, and
>>>>>>>> debugged before operators can deploy.
>>>>>>>>
>>>>>>>> Personally, I think 6man has the duty to ensure that no
>>>>>>>> radical changes go into the core protocols until *real
>>>>>>>> deployment experience* -- not of the "I can't deploy
>>>>>>>> because..." kind, but only of the "I deployed *and it
>>>>>>>> didn't work because...*" kind -- shows that there is really
>>>>>>>> a gap in functionality, and even then, to think extremely
>>>>>>>> carefully whether the long-term effects will be beneficial
>>>>>>>> or not. We're hoping that this IPv6 thing is going to last
>>>>>>>> us for the next 30 years. Let's not get too hung up on the
>>>>>>>> next 3.
>>>>>>>>
>>>>>>>>
>>>>>>>> Cheers, Lorenzo
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --------------------------------------------------------------------
>>>>>>>>
>>>>>>>>
>>>>>
>>>>>>>>
>> IETF IPv6 working group mailing list
>>>>>>>> [e-mail] Administrative Requests:
>>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>>>
>>>>>>>> --------------------------------------------------------------------
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>
>>>>>>>>
>> --------------------------------------------------------------------
>>>>>>> IETF IPv6 working group mailing list [e-mail]
>>>>>>> Administrative Requests:
>>>>>>> https://www.ietf.org/mailman/listinfo/ipv6
>>>>>>> --------------------------------------------------------------------
>>>>>>>
>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>>>>
>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list [e-mail] Administrative
>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>
>>>>
>>>
>>>
>>
>>
>
>
>