Subject: Dealing with fe80:xx:<interfaceid>, when xx != ::

From: Markku Savela <[email-masked]>
Date: Fri, 16 Mar 2001 11:23:06 +0200

While looking at the IPv6 code, I notice that I have two options in
recognizing my link local address as my own:

 1) only fe80::my-id

 2) or fe80:x:my-id, where x can be anything.

What should I do with incoming packet that has destination
fe80:x:my-id and 'x' != ::?

 a) drop it
 b) accept it as addressed to me
 c) something else?

Maybe some RFC actually tells this, but I don't remember seeing it
directly mentioned ...

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Fri, 16 Mar 2001 18:29:50 +0900

> 2) or fe80:x:my-id, where x can be anything.

	I guess you are looking at KAME code.  if so, please read through
	the following URL, section 1.3.  (1) is the legal one, (2) is
	used in KAME kernel internally and should never appear on wire
	nor userland API.

	http://www.kame.net/dev/cvsweb.cgi/kame/IMPLEMENTATION?rev=1.198

itojun

---

From: Markku Savela <[email-masked]>
Date: Fri, 16 Mar 2001 12:09:31 +0200

> 	used in KAME kernel internally and should never appear on wire

Yes, I know (1) is the legal. To rephrase: what should I do with the
illegal (2) variant? [stack must handle any incoming stuff, even if
illegal].

The address obviously belongs to my host, there cannot be any other
host having such address. To drop it, I have to do the additional
check for x=0 specially. Could also just leave the test out, and treat
is as legal packet.

The choice in here fixes possible future uses of those bits.

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Fri, 16 Mar 2001 20:06:28 +0900

>illegal (2) variant? [stack must handle any incoming stuff, even if

	if you are writing some other kernel code, drop them.
	KAME ip6_input() should make it sure to drop those - i'll check
	if we already do it or not.

	if you are writing userland applications, you need not to worry
	about it.  scoped IP addresses will come up as fe80::foobar, with
	sin6_scope_id filled in.

itojun

---

From: Francis Dupont <[email-masked]>
Date: Fri, 16 Mar 2001 15:34:51 +0100

In your previous mail you wrote:

=> no, there is only one!

    1) only fe80::my-id
   
=> this one.

=> this is internally used by some implementations:
 - you must not use it
 - implementers should not use it

    a) drop it
   
=> drop it (a) and send a bug report to implementers of the source.

=> RFC 1884 2.4.8 (on all types of interfaces where IPv6 transport have
been defined the n is 64):

    |   10     |
    |  bits    |        n bits           |       118-n bits           |
    +----------+-------------------------+----------------------------+
    |1111111010|           0             |       interface ID         |
    +----------+-------------------------+----------------------------+

Regards

[email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Fri, 16 Mar 2001 15:41:46 +0100

=> don't worry, there is no future use of those bits (in the past
there were some proposals which were rejected for many strong reasons).
But please don't apply this advice to site-local addresses.

---

From: Steve Deering <[email-masked]>
Date: Fri, 16 Mar 2001 08:31:12 -0800

>check for x=0 specially. Could also just leave the test out, and treat

To recognize your own addresses, you should be doing a full 128-bit
compare, not examining individual fields.  Just put all of your
own addresses in your routing table, with a prefix length of 128
bits and a "self" indicator, and let normal longest-match lookup
do its thing.  Embedding unnecessary knowledge of address structure
or address allocation policy in your code is Bad Practice.

>The choice in here fixes possible future uses of those bits.

Yes, if you start making assumptions about address formats or contents
beyond what the specifications require, and if your implementation gets
widely deployed, that may well become a major inhibitor to future
evolution of the protocol.  Please don't do that.

Steve

---

From: Francis Dupont <[email-masked]>
Date: Fri, 16 Mar 2001 17:51:41 +0100

>But please don't apply this advice to site-local addresses.
   
   My advice is the same for link-locals and site-locals: use a full 128-bit
   compare to recognize your own addresses.  That will continue to work,
   whether or not sites end up using non-zero values in the high-order
   part of their site-locals.
   
=> I believe the initial issue was a bit different: check or not check
that the must-be-zero bits are zero or not. Usually you should not
check them (ie. only do what you advice) but if you suspect some bugs
you may add a check in order to track them, in such a case if MBZ bits
become no more MBZ you'll be in trouble. My advice was this should not
happen for link-local addresses (so a check may safely be added and
forgotten) but not for site-local addresses (so if a check is added
then it must not be forgotten, usually it will be forgotten so it
should not be added)...

Regards

---

From: Steve Deering <[email-masked]>
Date: Fri, 16 Mar 2001 08:33:25 -0800

Steve

---

From: Markku Savela <[email-masked]>
Date: Fri, 16 Mar 2001 21:17:23 +0200

> do its thing.

That is obviously doable, when an interface has single id.

However, the issue came up when I started to explore the possibilities
of implementing the "privacy option", which could be interpreted (?)
in such way that an interface can have N different id's.

And if, you see a router avertising M new prefixes, you will have to
add N x M addresses to your routing list. And when an id or a prefix
expires, you have to rip off the matching addressess.

I was just looking, what would happen if I kept two lists: one for
prefixes and one for id's, and allowed any combination to be used
and recognized as own address. [For new id's I would do the DAD using
the link local address combined with the generated id].

-- 
Markku Savela <[email-masked]>

---

From: Robert Elz <[email-masked]>
Date: Sat, 17 Mar 2001 23:46:56 +1100

Date:        Fri, 16 Mar 2001 21:17:23 +0200
    From:        Markku Savela <[email-masked]>
    Message-ID:  <200103161917.VAA07948@burp>

  | I was just looking, what would happen if I kept two lists: one for
  | prefixes and one for id's, and allowed any combination to be used
  | and recognized as own address.

Don't do that.  For autoconfigured addresses it will probably work
(probably) but for assigned addresses, things will break badly.
There's no reason that on a link with prefixes A::/64 abd B::/64
I can't assign A::1 and B::2 to node X, and A::2 and B::1 to node Y.

Your scheme would break that totally.

kre

---

From: Markku Savela <[email-masked]>
Date: Sat, 17 Mar 2001 15:06:01 +0200

> I can't assign A::1 and B::2 to node X, and A::2 and B::1 to node Y.

Yes, I was talking about autoconfigured addresses. I did have in mind
allowing the full addresses being configured as an option.

But, it does raise a question: if you configure "A::1", and then some
host happens to autoconfigure "fe80::1" and performs DAD on this
(ADDRCONF specially mentions that you can do DAD on link-local, as id
should be unique, and can freely assume that A::1 is also usable. You
don't need to do DAD on every combination!).

This is messy. Either you allow all id/prefix combinations and require
that plain "id" part is always unique on link, or you forget the
prefix/id split and treat all combinations as independent addresses,
which *ALL* require DAD to be usable.

My interpretation of related RFC's (Neighbor Discovery, ADDRCONF) is
that they speak of id/prefix combinations. If this isn't true, some
text needs revision.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Jun-ichiro itojun Hagino <[email-masked]>
Date: Sun, 18 Mar 2001 02:45:58 +0900

>don't need to do DAD on every combination!).

	I suggest you to rnu DAD for every address you have (so run DAD for
	A::1).  the following fragment is from RFC2462 5.4.  I believe it works
	only if all the neighbors are using autoconfigured address only.
	as we are not sure about how the neighbors would behave, it is safer
	to run DAD for eveyr addresses you have.
	in the past, KAME omitted DAD for A::id, when A::id is autoconfigured
	from fe80::id.  with the latest code we run DAD for A::id as well.

itojun

      - Each individual unicast address SHOULD be tested for uniqueness.
        However, when stateless address autoconfiguration is used,
        address uniqueness is determined solely by the interface
        identifier, assuming that subnet prefixes are assigned correctly
        (i.e., if all of an interface's addresses are generated from the
        same identifier, either all addresses or none of them will be
        duplicates). Thus, for a set of addresses formed from the same
        interface identifier, it is sufficient to check that the link-
        local address generated from the identifier is unique on the
        link. In such cases, the link-local address MUST be tested for
        uniqueness, and if no duplicate address is detected, an
        implementation MAY choose to skip Duplicate Address Detection
        for additional addresses derived from the same interface
        identifier.
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Markku Savela <[email-masked]>
Date: Sun, 18 Mar 2001 22:05:49 +0200

> 	I suggest you to rnu DAD for every address you have (so run
> 	DAD for A::1).  the following fragment is from RFC2462 5.4.  I
> 	believe it works only if all the neighbors are using
> 	autoconfigured address only. as we are not sure about how the
> 	neighbors would behave, it is safer to run DAD for eveyr
> 	addresses you have.

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?

As it is now, and from the messages on this thread I deduce, that my
implementation must do the following things:

- at interface startup obtain id(s) and do DAD on it/them using link
  local address

- do DAD on each manually configured address

- on receiving RA, if it has M new prefixes (with A=1), and I have
  currently N id's, start M*N DAD processes, one for each
  combination. (at least TAHI seems to expect to see DAD on RA).

  Must handle situations where some combinations pass DAD and some
  not. => if I need some failed prefix, I have to generate a new id
  before I can use it

- any time I generate a id (privacy), and if I have M prefixes, do
  start M+1 DAD processes, one for each prefix and one for link local.

Of course, one could delay generating id and testing DAD until one has
a packet to send. I don't much like this, as it either requires
buffering packets at IP layer or dropping them, until situation gets
cleared. [yes, I already have to do it for ND, but I still don't like
it .. :-]