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

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Thu, 9 May 2002 08:26:32 -0500

>> 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:[email-masked]]
Sent: Thursday, May 09, 2002 9:23 AM
To: Bernie Volz (EUD)
Cc: Ole Troan; Ralph Droms; [email-masked]
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

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Sun, 12 May 2002 08:40:43 -0500

Jim:

Did you mistype here ... "This is not a good argument IMO for confirm."? What does anycast have to do with Confirm (well, the message might need to be anycast in NMBA networks but so would a Solicit, Information-Request, Rebind, ...).

- Bernie

-----Original Message-----
From: Bound, Jim [mailto:[email-masked]]
Sent: Sunday, May 12, 2002 12:58 AM
To: Thomas Narten; Bernie Volz (EUD)
Cc: Ole Troan; Ralph Droms; [email-masked]
Subject: RE: [dhcwg] dhcpv6-24: use of anycast 

One thing I don't agree with is that its hard to figure out of you have multicast existent on an interface?  All of us support some form of sysconf to do that.
This is not a good argument IMO for confirm.

(I am not against confirm) but to have it because of the API comment is not good).

/jim

> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
>

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 12 May 2002 22:13:30 -0400

Bernie,

Nope I was stating if I want to know if confirm is multicast I can.  Not having an API is a non issue.

/jim
-----Original Message-----
From: Bernie Volz (EUD) [mailto:[email-masked]]
Sent: Sunday, May 12, 2002 9:41 AM
To: Bound, Jim; Thomas Narten; Bernie Volz (EUD)
Cc: Ole Troan; Ralph Droms; [email-masked]
Subject: RE: [dhcwg] dhcpv6-24: use of anycast 

Jim:

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 12 May 2002 22:28:50 -0400

Ralph,

I don't believe we have any but will check for well known unicast.  But why not use well known multicast address on the link.  We do that today.

Either way it does not break any API or implementation.  

But using multicast there is well known way to join that group and we just say what it is reserved for?

Good idea.

regards,
/jim

> From: Ralph Droms [mailto:[email-masked]]
> Sent: Sunday, May 12, 2002 12:45 PM
> To: Bound, Jim
> Cc: Bernie Volz (EUD); Thomas Narten; Ole Troan; [email-masked]
> 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
> >
> > Sent: Thursday, May 09, 2002 9:27 AM
> > To: 'Thomas Narten'; Bernie Volz (EUD)

---

From: "Bound, Jim" <[email-masked]>
Date: Sun, 12 May 2002 22:35:21 -0400

Bernie,

*************************************
I don't think the link-scoped unicast address is a good idea. What would the prefix for this be? If it is the standard link-local prefix, what about all the hosts today that don't have code to check for this value.
**************************************

The client dhcpv6 code only needs know the address.  It does not affect IPv6 networking implementations at all.  And even if it was anycast thats handled by mgmt interface for the address set.

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

I agree with Thomas if anycast is used just use the first listner.  But we have an issue maybe and do with anycast right now.  What Ralph proposes works with well-known-unicast, anycast, or well-known-multicast as I suggested.  And it don't break anything.

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

I don't agree Ralphs suggestion is more clear, easy to implement, and fits the IPv6 architecture well.

thanks
/jim

---

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Mon, 13 May 2002 07:59:35 -0500

Ralph:

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

What happens if a client starts up before the DHCP server (or DAD fails to work because of temporary network issues) and uses this "reserved value"? In that case, the DHCP server can't run on that address and hence you don't have DHCP service.

Again, I think this is a bad idea.

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

I could be wrong, but as Thomas pointed out the existing technologies do have multicast solutions and they'd have an issue if they don't support multicast since ND (and DAD) wouldn't work if they don't provide it.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[email-masked]]
Sent: Monday, May 13, 2002 6:36 AM
To: Bernie Volz (EUD)
Cc: Bound, Jim; Thomas Narten; Ole Troan; [email-masked]
Subject: RE: [dhcwg] dhcpv6-24: use of anycast 

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?

>"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
>
>From: Ralph Droms [<mailto:[email-masked]>mailto:[email-masked]]
>link-scoped unicast address for DHCP?  If we use a unicast address, only
>right?  For point-to-point links that's not a problem - there can only be
>there any multiple access link technologies that don't provide or emulate
>multicast?
>
>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;
>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
>standards than the use of an anycast address?  Does the assignment of a
>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
> > 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
> >
> > From: Bernie Volz (EUD) 
> [<mailto:[email-masked]>mailto:[email-masked]]
> > From: Thomas Narten [<mailto:[email-masked]>mailto:[email-masked]]