Re: there _is_ IPv6 NAT - just look for it

[Alexandru Petrescu <[e-mail]>]

Le 16/03/2014 13:02, Hesham Soliman a écrit :
>
> Brian,
>
>>>
>>> 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.

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