DHCPv6 currently uses a site-scoped multicast address as the default for
forwarding messages from a relay agent to servers.  The relay agent can be
configured with a list of unicast addresses for servers instead of using
the site-scoped multicast address.

DHCPv6 also depends on link-local addresses for communication between the
client and the on-link relay agent.

- Ralph

On Sat, 8 Jun 2002 [EMAIL PROTECTED] wrote:

> >> For link-local addresses, as long as the scope is
> >> well-defined, what are your objections?
> >for the most part, they're only a problem if you try to use
> >them in applications (where zero-configuration appliances
> >are an important subset of applications)
> >part of the problem is that the scope of link-local addresses
> >is *not* well-defined from an application's point of view,
> >since applications in general don't know, and shouldn't have
> >to know, about network topology.
>
>       as long as the applications are properly implemented with sockaddrs,
>       they are okay.  the problem reside in protocols that pass IPv6
>       addresses in payloads (since view of the scope is different by nodes),
>       including:
>       - FTP (EPSV/EPRT does not help - for instance, how do you decide
>         the scope zone for data connection?)
>       - DNS (AAAA/PTR does not represent scope correctly)
>       - and all NAT-unfriendly protocols
>
>       I'm okay to see site-local IPv6 address to go away, however, I'm
>       worried because there are more than a couple of protocols designed with
>       site-local IPv6 address in mind (DHCPv6, router renumbering, ...).
>
>       we need to keep link-local IPv6 address at least for ND.  use of
>       link-locals within zeroconf environment needs further study.
>
> itojun
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [EMAIL PROTECTED]
> --------------------------------------------------------------------
>


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to