A while back on this list I said

> Why cannot id's on link be simply defined as:
> 
> - Any active normal id on the link can be assigned only to one host at
>   at a time.
> 
> - in ADDRCOF, DAD would simply reduce to a question: is the id part of
>   the address same as one of my assigned ids? It would not matter
>   which prefix you use to do the DAD.
> 
> - neighbor discovery would not need any changes. That would still use
>   full addresses.
> 
> What are the objections against above simple fix? What breaks?

Can we please have this change? Other solutions seem extremely messy
(multiple DAD's, and other complexities). Mostly, RFC-2462 change... 

What I have experimentally coded as "defending of my id"

 - if system sees DAD for an address, only ID part is compared (prefix
   ingored). If id is tentative, declare it as duplicate. If id is
   already assigned to me with some prefix, I send NA as a reply
   (regardles whether the prefix in DAD is actually used by me or
   not).

 - if I see a valid NA, which matches my id:

   1) if my id is tentative, declare it duplace.

   2) if NA is for my assigned address (prefix+id), ignore it
      (obviously, two hosts have have same address on link, bad
      situation)

   3) if NA is not for my assigned address (id matches, but prefix
      does not), process it as normal NA. => as long as I never see
      this prefix in RA (with A=1), things work fine.

To make it easier for configuring manual permanent IPv6 addresses for
some known servers, it might be good to put some range of values in
the ID part aside for that purpose? prefix::[1-1023]? (And change
rules of randomly generated id's to avoid this range).
--------------------------------------------------------------------
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