RE: [dhcwg] dhcpv6-24: use of anycast

[Ralph Droms <[e-mail]>]

Bernie - I'm not sure the link-scoped unicast address is such a good idea, 
either.  However, I do have some comments about your concerns (in line)...

- Ralph

At 08:34 PM 5/12/2002 -0500, Bernie Volz (EUD) wrote:

>Ralph:
>
>I don't think the link-scoped unicast address is a good idea. What would 
>the prefix for this be?

The standard link-local prefix

>  If it is the standard link-local prefix, what about all the hosts today 
> that don't have code to check for this value.

There's no need to check for this reserved value - the IPv6 stack will do 
normal DAD.  I don't think the stack has to know about the use of the 
reserved address for DHCPv6 - just DHCPv6 applications need to know.


>I think we're best left with letting this issue be resolved by the first 
>link that needs it (as Thomas originally suggested).

That's OK - except for those link technologies that are already 
defined?  Or, do we go ahead with DHCPv6 and make a note that existing 
"IPv6 over X" docs should review the need for special handling for DHCPv6?


>So, perhaps we should simply say:
>
>"If the link supports multicast, the multicast address MUST be used. 
>Otherwise, the link over IPv6 specification needs to specify what the DHCP 
>Client must use."
>
>- Bernie
>
>-----Original Message-----
>From: Ralph Droms [<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Sunday, May 12, 2002 12:45 PM
>To: Bound, Jim
>Cc: Bernie Volz (EUD); Thomas Narten; Ole Troan; [e-mail]
>Subject: RE: [dhcwg] dhcpv6-24: use of anycast
>
>
>Jim makes a good good point about anycast.  Given the current
>discussion about anycast addresses and hosts on the ipngwg mailing
>list, it would be premature to specify site-local anycast for DHCPv6.
>
>What about link-local only "anycast" - perhaps that's not really
>"anycast" because there's no routing?
>
>Instead of an anycast address, suppose we request the reservation of a
>link-scoped unicast address for DHCP?  If we use a unicast address, only
>one relay agent or server on a link can be listening on that address,
>right?  For point-to-point links that's not a problem - there can only be
>one relay agent or server at the other end of the point-to-point link.
>I'm still not clear about multiple-access links and multicast - are
>there any multiple access link technologies that don't provide or emulate
>multicast?
>
>Is there a precedent for the reservation of a link-scoped, well-known
>unicast address?
>
>Using a link-scoped unicast address, the first relay agent or server to
>bind to the address gets to use it.   I'm not familiar with the IPv6 API;
>I assume that an application (with sufficient privilege) can make a
>request to assign a specific address to an interface.  I guess the stack
>does DAD on the requested address and the request fails if the address is
>already in use?
>
>I'm not thrilled with my idea - it sounds fairly ugly.  Does it break or
>bend fewer existing standards, or require the definition of fewer new
>standards than the use of an anycast address?  Does the assignment of a
>well-known link-scoped unicast address for DHCP set a precedent we'd
>rather not set?
>
>The use of the unicast address could be further discouraged by including a
>restriction that relay agents and servers MUST NOT listen on the unicast
>address and clients MUST NOT send messages to the unicast address on a
>link that supports multicast.
>
>- Ralph
>
>  On Sun, 12 May 2002, Bound, Jim wrote:
>
> > Thomas,
> >
> > I am fine with this too.  But what we are permitting the server to have 
> an anycast address and the addr arch says don't do this?  Will it not be 
> kicked  back again by the IESG because we did that?
>
> >
> > thanks
> > /jim
> >
> > -----Original Message-----
> > From: Bernie Volz (EUD) 
> [<mailto:[e-mail]>mailto:[e-mail]]
> > Sent: Thursday, May 09, 2002 9:27 AM
> > To: 'Thomas Narten'; Bernie Volz (EUD)
> > Cc: Ole Troan; Ralph Droms; [e-mail]
> > Subject: RE: [dhcwg] dhcpv6-24: use of anycast
> >
> >
> > >> What we probably should say is that the client MUST use the
> > >> multicast address if the interface on which it is sending the
> > >> message supports multicast. Otherwise, it may use the anycast
> > >> address.
> > >
> > >This is OK with me. Just so long as it's clear that the anycast usage
> > >is only link-local and is only for reaching servers (and relay agents)
> > >on the same link. This seems like a straightforward thing to get
> > >right.
> > Sounds fine to me.
> > - Bernie
> > -----Original Message-----
> > From: Thomas Narten [<mailto:[e-mail]>mailto:[e-mail]]
> > Sent: Thursday, May 09, 2002 9:23 AM
> > To: Bernie Volz (EUD)
> > Cc: Ole Troan; Ralph Droms; [e-mail]
> > Subject: Re: [dhcwg] dhcpv6-24: use of anycast
> >
> >
> > > The only issue with this is that DHCP usually runs as an application
> > > and is therefore only able to access that information which the
> > > lower layers (via APIs) make available.
> > Understood.
> > > Determining whether multicast is supported or not is pretty standard
> > > from the socket API. However, determining that a particular
> > > interface is a specific media type may be difficult.
> > OK.
> > > Therefore, there is some value in providing a clear direction here
> > >  that is also relatively easy to implement.
> > Agreed.
> > > If all interface types provide multicast (either inherently or via
> > > some type of emulation), there is little need to ever use the
> > > anycast address and so what harm is there in specifying it.
> > The harm is that a) we may define something that isn't useful (which
> > may cause problems when deployed because some implementations choose
> > use the feature even if it doesn't work as intended). b) clients may
> > choose to send to anycast addresses, but if servers aren't configured
> > to deal with them, we don't get interoperability, so specifying that
> > clients MAY do something really implies (to me) that server SHOULD (or
> > maybe even MUST) be prepared to handle such packets from clients. If
> > the client  can't expect a server to handle something, there is little
> > point in clients implementing the feature either.
> > My general opinion: if its not clear something is useful, and it's not
> > obvious what the details should be, including the feature distracts
> > from the overall goal of getting the spec done. The more one can
> > remove, the fewer details that have to be gotten right.
> > > What we probably should say is that the client MUST use the
> > > multicast address if the interface on which it is sending the
> > > message supports multicast. Otherwise, it may use the anycast
> > > address.
> > This is OK with me. Just so long as it's clear that the anycast usage
> > is only link-local and is only for reaching servers (and relay agents)
> > on the same link. This seems like a straightforward thing to get
> > right.
> > Thomas
> >


_______________________________________________
dhcwg mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg