Re: [Int-area] Revving draft-intarea-shared-addressing-issues

Ok, I agree that it's good to point out that any shared address should be
from space designated as such.  Otherwise it will break the widely used
assumption that public IPv4 addresses are "globally unique" addresses
and hence break many protocols and applications.

-Dave

> -----Original Message-----
> From: Dan Wing [mailto:dwing@cisco.com]
> Sent: Monday, June 14, 2010 1:45 PM
> To: Dave Thaler; 'Bernard Aboba'; ford@isoc.org
> Cc: int-area@ietf.org; brian.e.carpenter@gmail.com; draft-ford-shared-
> addressing-issues@tools.ietf.org; lorenzo@google.com
> Subject: RE: [Int-area] Revving draft-intarea-shared-addressing-issues
> 
> 
> 
> > -----Original Message-----
> > From: Dave Thaler [mailto:dthaler@microsoft.com]
> > Sent: Monday, June 14, 2010 1:23 PM
> > To: Dan Wing; 'Bernard Aboba'; ford@isoc.org
> > Cc: int-area@ietf.org; brian.e.carpenter@gmail.com;
> > draft-ford-shared-addressing-issues@tools.ietf.org; lorenzo@google.com
> > Subject: RE: [Int-area] Revving draft-intarea-shared-addressing-issues
> >
> > > -----Original Message-----
> > > From: Dan Wing [mailto:dwing@cisco.com]
> > > Sent: Monday, June 14, 2010 1:16 PM
> > > To: 'Bernard Aboba'; Dave Thaler; ford@isoc.org
> > > Cc: int-area@ietf.org; brian.e.carpenter@gmail.com;
> > draft-ford-shared-
> > > addressing-issues@tools.ietf.org; lorenzo@google.com
> > > Subject: RE: [Int-area] Revving
> > draft-intarea-shared-addressing-issues
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Bernard Aboba [mailto:bernard_aboba@hotmail.com]
> > > > Sent: Monday, June 14, 2010 1:05 PM
> > > > To: dthaler@microsoft.com; dwing@cisco.com; ford@isoc.org
> > > > Cc: int-area@ietf.org; brian.e.carpenter@gmail.com;
> > > > draft-ford-shared-addressing-issues@tools.ietf.org;
> > lorenzo@google.com
> > > > Subject: RE: [Int-area] Revving
> > draft-intarea-shared-addressing-issues
> > > >
> > > > The NAT box can use its public IPv4 address to enable
> > 6to4, thereby
> > > > providing IPv6 support for hosts "behind" it.  Why would
> > this result
> > > > in a disconnected IPv6 island?
> > >
> > > Diagram of what I understand the problem to be with 6to4
> > behind another NAT:
> > >
> > >   IPv6 host--+
> > >               \
> > >                +---[home NAT]----[Carrier's NAT]---[Internet]
> > >               /      ^       ^                  ^
> > >   IPv6 host--+       ^       ^                  ^
> > >                      ^       ^             IP address sharing
> > >                      ^       ^             with multiple
> > >                      ^       ^             subscribers
> > >                      ^       ^
> > >                      ^     the in-home NAT's WAN address
> > >                      ^     is not publicly routable
> > >                      ^
> > >                      ^
> > >                this in-home
> > >              NAT turns on 6to4
> >
> > The in-home NAT cannot turn on 6to4, it's simply not possible.
> > To turn on 6to4 per the RFC one has to have a globally unique
> > IPv4 address, which it doesn't in the diagram above.
> 
> That works until the Carrier NAT provides a non-RFC1918 address to the home
> NAT.  I don't believe anything requires the carrier's NAT provide RFC1918
> addresses.  draft-nishitani-cgn doesn't mention RFC1918.  Do we need such a
> requirement to avoid the problem of 6to4 being enabled?
> 
> Things like draft-miles-behave-l2nat can give the NAT any address it likes,
> including giving every NAT the same public,
> non-RFC1918 IPv4 address:
> 
>    "... This
>    technique can be leveraged post IPv4-exhaustion within the
>    constraints of existing host and CPE implementations to assign the
>    exact same public IPv4 address to every subscriber session and to
>    then perform IPv4-to-IPv4 NAT on the subscriber traffic.  For
>    example, multiple PPP subscribers could be assigned the exact same
>    IPv4 address through IPCP and the L2-Aware NAT will translate all
>    packets to an external/WAN public IPv4 address by including
>    subscriber-identifier as an additional delimiter in the NAT mapping
>    table."
> 
> -d
> 
> 
> > -Dave
> >
> > >
> > > -d
> > >
> > > > > From: dthaler@microsoft.com
> > > > > To: dwing@cisco.com; ford@isoc.org
> > > > > Date: Mon, 14 Jun 2010 19:04:31 +0000
> > > > > CC: int-area@ietf.org; brian.e.carpenter@gmail.com;
> > > > draft-ford-shared-addressing-issues@tools.ietf.org;
> > lorenzo@google.com
> > > > > Subject: Re: [Int-area] Revving
> > > > draft-intarea-shared-addressing-issues
> > > > >
> > > > > > Some routers enable 6to4 [RFC3056] on their WAN link.
> > > > 6to4 requires a
> > > > > > publicly-routable IPv4 address. Enabling 6to4 behind a
> > > > NAT causes a
> > > > > > disconnected IPv6 island."
> > > > >
> > > > > The last sentence above is incorrect. The second sentence
> > > > is correct.
> > > > > So one cannot "enable" 6to4 behind a NAT since one has no
> > > > > publically-routable IPv4 address. Hence one does not get an IPv6
> > > > > island. One gets no IPv6 at all (from 6to4 anyway).
> > > > >
> > > > > -Dave
> > > > >
> > > > > _______________________________________________
> > > > > Int-area mailing list
> > > > > Int-area@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/int-area
> > > >
> > > >
> > >
> >
> 