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