Hi,
Thus wrote jouni korhonen ([email protected]):
> On Oct 21, 2010, at 8:34 AM, S.P.Zeidler wrote:
> > Thus wrote [email protected] ([email protected]):
> >
> >> Section 11 of your draft states that the ULA prefix should be selected
> >> randomly.
RFC4193 states: 'Locally assigned Global IDs MUST be generated with a
pseudo-random algorithm consistent with [RANDOM].' too.
> >> Have you considered selection of ULA prefix(es) for internal network in
> >> such a manner that it/they can be translated to NAT uplink's /64 prefix in
> >> checksum neutral fashion?
> >
> > That will likely not work if you have several prefixes that you want to
> > translate into.
>
> Teemu is referring here to a specific deployment scenario, which is using a
> cellular phone as a mobile router. In this case, there is only one uplink and
> the uplink always has a single /64. I admit the deployment scenario is rather
> specific/limited but not necessarily a corner case (expecting that the
> penetration of cellular phones with e.g. WLAN is going to be wide spread).
In this case, do you expect the network connected to the phone to be
structured? Even if the ULA is determined randomly, it is still a /48 and
the /64 picked to be used on the inside need not be random at all.
Remains the question why you'd bother with NAT66? What advantage does it
deliver over using the public addresses directly?
regards,
spz
--
[email protected] (S.P.Zeidler)
_______________________________________________
nat66 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nat66
