RE: But are we talking IPv6 only? That's how I read the draft. (Re: Some suggestions for draft-ietf-v6ops-cpe-simple-security-03)

["Templin, Fred L" <Fred.L.Templin@boeing.com>]

>-----Original Message-----
>From: Dan Wing [mailto:dwing@cisco.com] 
>Sent: Thursday, August 28, 2008 8:27 AM
>To: Templin, Fred L; 'james woodyatt'; 'IPv6 Operations'
>Subject: RE: But are we talking IPv6 only? That's how I read 
>the draft. (Re: Some suggestions for 
>draft-ietf-v6ops-cpe-simple-security-03)
>
>> >My confusion -- which persists even after reading your email -- is
>> >what this home network (with a dual-stack CPE) looks like:  which 
>> >device(s) terminate IPv6-over-IPv4 tunnels (the CPE itself?  Or a 
>> >host behind the CPE?), which devices get IPv4 addresses (only the 
>> >CPE itself, or also devices behind the CPE?), and so on.
>> 
>> In the case of unsolicited incoming IPv6-in-IPv4 packets,
>> if the CPE is a 6to4 or ISATAP router, the CPE terminates
>> the tunnel. (If the site behind the CPE uses ISATAP, the
>> packets are then admitted into a *different* tunnel that
>> spans the site behind the CPE.)
>
>(Just stating the obvious, but I want to point out) this 
>requires the CPE itself have a publicly-routable v4 address.

True for 6to4, but not true for ISATAP; if the CPE were
assigned a private address on it's provider-side interface
it could still be configured as an ISATAP router.

Fred
fred.l.templin@boeing.com

>> If the CPE is *not* configured as either a 6to4 or ISATAP
>> router, a Teredo tunnel could still be used to direct
>> encapsulated packets through an open port in the CPE
>> and to the final destination within the site. (That is,
>> if the port is being kept open through keepalives sent
>> by the final destination.)
>
>Which requires the host behind the CPE (the one running
>Teredo) first start up Teredo.  This changes how 'unsolicited
>incoming packets'
>
>> I haven't read the draft, but I'm pretty sure this stuff
>> is well known within the v6ops community; does the draft
>> fail to mention and/or misrepresent any of the above?
>
>Yes, I am coming into the middle of a discussion; life is
>full of such events.  My apologies.
>
>But the assumed model(s) need to be explained, in the draft, 
>so that it is clear how those models apply to dual-stack-lite 
>and to IVI/NAT64/NAT-PT -- all of which change the assumptions
>(due to lack of publicly-routable v4 address for some of
>those solutions).  Or, alternatively, if it is this draft's
>intent that its model for v6-in-v4 is only intended to work 
>if the CPE has a publicly-routable v4 address.
>
>-d
>
>