RE: ULAs [Re: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC]

["Dan Wing" <dwing@cisco.com>]

> -----Original Message-----
> From: Mark Smith 
> [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org] 
> Sent: Tuesday, January 05, 2010 2:40 PM
> To: Dan Wing
> Cc: 'Hemant Singh (shemant)'; 'Brian E Carpenter'; 'Fred 
> Baker (fred)'; v6ops@ops.ietf.org; kurtis@kurtis.pp.se; 
> rbonica@juniper.net; draft-ietf-v6ops-ipv6-cpe-router@tools.ietf.org
> Subject: Re: ULAs [Re: draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC]
> 
> Hi Dan,
> 
> On Tue, 5 Jan 2010 14:09:34 -0800
> "Dan Wing" <dwing@cisco.com> wrote:
> 
> >  
> > 
> > > -----Original Message-----
> > > From: Mark Smith 
> > > [mailto:ipng@69706e6720323030352d30312d31340a.nosense.org] 
> > > Sent: Tuesday, January 05, 2010 2:06 PM
> > > To: Hemant Singh (shemant)
> > > Cc: Dan Wing (dwing); Brian E Carpenter; Fred Baker (fred); 
> > > v6ops@ops.ietf.org; kurtis@kurtis.pp.se; rbonica@juniper.net; 
> > > draft-ietf-v6ops-ipv6-cpe-router@tools.ietf.org
> > > Subject: Re: ULAs [Re: 
> draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC]
> > > 
> > > On Tue, 5 Jan 2010 15:37:52 -0600
> > > "Hemant Singh (shemant)" <shemant@cisco.com> wrote:
> > > 
> > > > 
> > > >   >-----Original Message-----
> > > > >From: Dan Wing (dwing) 
> > > > >Sent: Tuesday, January 05, 2010 3:16 PM
> > > > >To: 'Brian E Carpenter'
> > > > >Cc: Fred Baker (fred); v6ops@ops.ietf.org; kurtis@kurtis.pp.se;
> > > > rbonica@juniper.net; 
> draft-ietf-v6ops-ipv6-cpe-router@tools.ietf.org
> > > > >Subject: RE: ULAs [Re: 
> > > draft-ietf-v6ops-ipv6-cpe-router-03.txt WGLC]
> > > > 
> > > > >I'm asking for text to provide motivation for the existing L-1 
> > > > >requirement (which reads "The IPv6 CE router MUST support ULA 
> > > > >addressing [RFC4193]").
> > > > 
> > > > About two years back Brian Carpenter gave the dentist's 
> > > office as one
> > > > motivation for use of ULA in the home with the CE Rtr. 
> The dentist's
> > > > office network is setup once and that's how it runs for a 
> > > long time.  If
> > > > the Internet WAN link of the dentist's office CE Rtr 
> goes down, the
> > > > dentist can still print from his office PC to his printer 
> > > which are both
> > > > using ULA.  The other motivation that is also in emails of v6ops
> > > > archives is that what does one do for configuration of the 
> > > CE Rtr right
> > > > out of shrink-wrap?  The user bought the device from retail 
> > > and powered
> > > > it up in the home before attaching the CE Router to any 
> > > WAN.  Without a
> > > > GUA (Globally Unique Address), how does one configure 
> the CE Rtr if
> > > > using link-local is spotty at best to access a device with 
> > > a link-local
> > > > URL.  You see, the link-local can be common to all LAN 
> > > ports of the CE
> > > > Rtr and that is why it's not a good address to use to 
> > > configure the CE
> > > > Rtr in a web browser.  So that leaves only the GUA 
> > > (auto-configured on
> > > > the CE Rtr on power up) to configure the device with using a web
> > > > browser.  Auto-configuration of the CE Rtr is part of 
> the Phase II
> > > > document, so any more details in the current CE Rtr doc 
> > > (Phase I) will
> > > > be skipped.
> > > 
> > > Somewhat related, is there room in this ID for adding 
> > > Zerconf/multicast
> > > DNS etc. for the convenience of browsing or device name based 
> > > discovery
> > > to be able to configure the device via a web/ software application
> > > interface? ULAs are great for this purpose, but end-users 
> should never
> > > have to work out what they are type them into anywhere, 
> and I think
> > > there should be a standard mechanism to discover CPE configuration
> > > interfaces. Or is it out of scope?
> > 
> > The hosts (and users on the hosts) might care, but the CE router
> > doesn't need to be involved in mDNS, does it?  Feels out of scope
> > to me, for whatever that's worth.
> > 
> 
> With residential IPv4 CPE, it's easy enough for customers to type in
> e.g. 192.168.1.1 off of a supplied piece of paper in the box to get to
> the CPEs configuration interface to type in authentication details
> etc., and easy enough for helpdesk staff to get customers to type in
> over the phone for service troubleshooting (in the context of customer
> owned and chosen CPE, which is the case here in .au). Different CPE do
> use different RFC1918 addresses, however the set of them is fairly
> small, and they're usually all within the 192.168/16 range. Sometimes
> it's printed on the label on the bottom of the device.
> 
> Having an end-user accurately type in an equivalent IPv6 address, even
> a common one, is going to be hard,

Agreed.  Made worse because the HTTP syntax needs "[]" around 
an IPv6 address literal.

> and with ULAs being customer
> specific, a lot of time would be spent just working with the customer
> to determine what the ULA of their CPE is, to then access the web
> interface.

Some IPv4 CPE solve that problem by hijacking DNS queries (and 
sending, as the response, the NAT's internal IP address) or by 
intercepting outbound TCP/80 and re-routing it to the NAT's HTTP
server.  Once the IPv4 CPE is happily configured, it steps out
of the way and quits interfering.

I can see everyone shaking their heads, because IETF would not
sanction doing such nasty things.  (However, this is why 
configuring IP is considered 'hard', but I digress.)

mDNS would be better than the existing techniques.

> Some vendors get around these issues by supplying setup software
> that performs the device discovery. While that's a user friendly
> solution, for a helpdesk, the ubiquity of a web browser and web
> interface on the CPE is a useful and reliable minimum.
> 
> I suppose these issues could be out of scope for this draft, if it is
> focused only on the IPv6 functions the CPE has to support, rather than
> issues like configuration interfaces etc. mDNS possibly falls across
> the boundary between in and out of scope - useful if it's a 
> fundamental
> feature of all IPv6 CPE (in scope), but only really there to 
> facilitate
> CPE configuration (out of scope).

We had a thread, a year ago, on an IETF list (I thought it was v6ops?) about
how we might do something like http://ce-router, but I don't recall where it
went.

I agree with you that a standard way for the CE router to be found would be
beneficial, so the vendor could create a one-page instruction manual that
shows its simple-to-type HTTP URI.  

Could we get consensus that mDNS is the way to accomplish this goal?  For
example, when you say mDNS do you mean RFC4795 (which was previously called
draft-ietf-dnsext-mdns), draft-mdns-rfc-informational-00 (published November
2009), or draft-cheshire-dnsext-multicastdns.  I believe you mean
draft-cheshire-dnsext-multicastdns.

-d


> Regards,
> Mark.
> 
> 
> 
> > -d
> > 
> > 
> > > Regards,
> > > Mark.
> > > 
> > > > 
> > > > If none objects that motivation for use of ULA needs to be 
> > > included as
> > > > text in the CE Rtr doc, what we can do is work on a formal 
> > > version of
> > > > what I have summarized above.
> > > > 
> > > > Further, in an earlier version of the CE Rtr we also said 
> > > the ULA and
> > > > the GUA coexist on a LAN network interface.  Since the addresses
> > > > coexist, here is what our earlier version said about RFC 3484.  
> > > > 
> > > > "... every LAN interface has a link-local unicast address, 
> > > a ULA, and a
> > > > GUA.  Therefore, the interface has to apply source address 
> > > selection to
> > > > determine which address to use as a source for outgoing 
> > > packets.  Since
> > > > the GUA and ULA have a larger scope than the link-local 
> > > address (rule #2
> > > > of [RFC3484]), the GUA or ULA will be used as a source 
> address of
> > > > outgoing packets that are not subject to rule #1.  For 
> > > source address
> > > > selection between a GUA and ULA, rule #8 of [RFC3484] 
> will be used."
> > > > 
> > > > In the -03 version we have removed such text.
> > > > 
> > > > Thanks,
> > > > 
> > > > Hemant
> > > > 
> >