Subject: Re: [v6ops] On 6204-bis

From: Ray Hunter <[email-masked]>
Date: Sat, 22 Oct 2011 19:18:05 +0200

This exchange to me demonstrates a fundamental flaw in the approach of 
the current document.

On the one hand, the document seems to attempt to act as a specification 
list that can be sent by an ISP to equipment vendors to define a CPE 
router, including the WAN interface (DS-Lite, 6rd etc.) which to me is 
essentially a private interface within the network service provider cloud.

And yet on the other hand it does not define or provide an open L3 
router-to-router connection or interface on which to attach a Homenet, 
on what should essentially be the public side.

As there only seem to be two interface types defined in this standards 
track document (WAN-side and a flat LAN-side with directly connected 
hosts), an end user or vendor wishing to tweak the local Homenet 
configuration (e.g. by adding a new WiFi radio type) is left with the 
choice of replacing the entire ISP CPE router by connecting to the 
WAN-side interface and complying with all of the internal configuration 
items and specifications of each and every ISP as well adding their own 
little expansion, or connecting to the LAN-side interface and spoofing 
the ISP CPE router into thinking it is talking to an end IPv6 host on a 
flat LAN.

That to me is a sure fire way of guaranteeing that NAT66 is going to be 
widely deployed, everywhere.

I urge the authors to work with the Homenet WG to define a suitable open 
L3 router-to-router interface on the ISP CPE router that could be used 
to connect multiple end-user-owned router devices if required, and which 
could thus act as a Homenet attachment point.

[I've already posted my architectural level ideas about defining devices 
with optional "stack in" / "stack out" ports on the Homenet list, so I 
won't repost them here]

regards,
RayH

> Subject:
> Re: [v6ops] On 6204-bis
> From:
> Lorenzo Colitti <[email-masked]>
> Date:
> Sat, 22 Oct 2011 08:56:14 -0700
>
> To:
> "Hemant Singh (shemant)" <[email-masked]>
> CC:
> "[email-masked] WG" <[email-masked]>
>
> Precedence:
> list
> MIME-Version:
> 1.0
> References:
> <[email-masked]> 
> <21884_1319204223_[email-masked]> 
> <[email-masked]> 
> <[email-masked]>
> In-Reply-To:
> <[email-masked]>
> Message-ID:
> <[email-masked]>
> Content-Type:
> multipart/alternative; boundary=000e0cd6ad36c29fdd04afe53a1f
> Message:
> 7
>
>
> On Oct 22, 2011 9:15 PM, "Hemant Singh (shemant)" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> > >I don't think Mark opposes the two - I think he's simply saying 
> (and, FWIW, I agree) that DS-lite is not about providing IPv6, it's 
> about providing IPv4. So it doesn't necessarily belong in a >document 
> that describes what an IPv6 CE router should do.
> >
> > It's totally subjective that DS-Lite is labeled as an IPv4 
> technology while 6rd is not.  I would just as well say 6rd carries 
> data from the home in an IPv4 tunnel, so 6rd is also IPv4 technology.  
>  A DS-Lite deployment already has IPv6 at the subscriber edge and the 
> SP edge to the Internet backbone.    I would argue that for 6rd the SP 
> network is less IPv6 ready since IPv6 data from the subscriber edge is 
> heading to the SP IPv4 network.
>
> 6rd is a technology to deliver IPv6 to users. DS-Lite is a technology 
> to deliver IPv4 to users. If you wanted to, you could perfectly well 
> implement DS-Lite on the WAN interface without ever providing IPv6 
> connectivity to the user at all.
>
> If you accept that an IPv6 CE router is a device that brings IPv6 
> connectivity to users, then DS-Lite does not necessarily belong in 
> there, because it does not provide the user with IPv6 connectivity.
>
>