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

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

Thomas:

>Perhaps one could take the approach that DHC uses link-local multicast
>by default, unless the specific link-layer over FOO document says use
>anycast. This is cleaner than saying "use anycast over NBMA" because
>its clearly specified on a case-by-case basis.

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.

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.

Therefore, there is some value in providing a clear direction here that is also relatively easy to implement.

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.

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.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:[email-masked]]
Sent: Thursday, May 09, 2002 8:04 AM
To: Ole Troan
Cc: Ralph Droms; [email-masked]
Subject: Re: [dhcwg] dhcpv6-24: use of anycast 

Ole Troan <[email-masked]> writes:

> >> If all IPv6 links support multicast, then we don't need the anycast address
> >> for DHCP.
> >
> > This would be my assumption. Do folks have examples of link types they
> > are concerned about?

> ATM,

See RFC 2491 and 2492. Multicast is supported. At least in the case of
SVC/PVC. Not clear that anyone uses anything else (i.e., pure NBMA
cloud).

> Frame Relay RFC2491)

Ditto.

> ISDN/PSTN

Always modeled as a p-2-p link, so mcast is trivially defined.

> MPLS

MPLS is a funny one. I don't think it is typically viewed as an NBMA
cloud. Also, MPLS is used within the core, by routers, and NOT at the
edges, so I'd think DHC is not really applicable in general here.

> 6to4

Not clear that this is applicable. The router defining 6to4 is an IPv4
box on the interface and uses DHCPv4. It does provide IPv6 support,
but this is explicitely in an environment where IPv6 is not supported
by the upstream. So DHCPv6 doesn't seem applicable; it it was, why
would one even be using 6to4?

> ISATAP.

Not clear this is applicable.

> if routers use DHCP (e.g Prefix Delegation) then support is needed
> for the first set of media. hosts connecting through an ISATAP cloud
> could very well need DHCP I should think.

This is not at all clear to me.

99% of the applicability of DHCv6 will be traditional media, i.e.,
Ethernets.

Another thought. The IPv6 over foo documents provide specifics for how
to run IPv6 over that media. In some cases, those documents can
override defaults for running IPv6 over a media in general. For
example, one can change the number of times one retransmits in
DAD. The default is 1, but a specific document can make that 0 or 2,
etc.

Perhaps one could take the approach that DHC uses link-local multicast
by default, unless the specific link-layer over FOO document says use
anycast. This is cleaner than saying "use anycast over NBMA" because
its clearly specified on a case-by-case basis.

Thomas

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

---

From: Thomas Narten <[email-masked]>
Date: Thu, 09 May 2002 09:22:58 -0400

> 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