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)

["Dan Wing" <[e-mail]>]

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

> 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