Subject: RE: W.G. Last Call on "Default Address Selection for IPv6"

From: "Christian Huitema" <[email-masked]>
Date: Fri, 1 Jun 2001 14:52:17 -0700

In fact, there is only one debatable MUST that remains -- at the end of
section 4, the reference to "Rule 2 (prefer appropriate scope) MUST be
implemented and given high priority because it can affect
interoperability." Rule 2 essentially states that one should pick the
lowest scope that it still higher or equal than the destination. There
are plenty of reasons to override that, e.g. different performance of
different interfaces, etc. A SHOULD would be in order.

-- Christian Huitema

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Friday, June 01, 2001 10:35 AM
> To: Christian Huitema
> Cc: Francis Dupont; Bob Hinden; [email-masked]
> Subject: RE: W.G. Last Call on "Default Address Selection for IPv6"
> 
> Christian,
> 
> Which MUST in the spec do you feel is inappropriate?
> 
> There are only 6 MUST/MUST NOT and as far as I can tell
> they specify constraints that effect interoperability or the protocols
> actually working (e.g. not letting a link local addresses for
> link A be used on as a source address for packets sent on link B).
> 
>   Erik

--------------------------------------------------------------------
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: Alain Durand <[email-masked]>
Date: Sat, 02 Jun 2001 10:54:58 -0700

I have a comment on the "last resort" rule, that say, everything being equal,
perform longest prefix match an all bits from 1 to 128.

I would like to suggest to limit the match to the first 64 bits.

The danger of doing match on all the bits is to have unpredictable behavior
and difficult to diagnose problem.

Let say that you have to hosts A & B on the same IPv6 subnet, and both host
have another direct connection (e.g. serial link or another ethernet link
at a lower speed) for back-up
Let say that all addresses have global

---

From: Alain Durand <[email-masked]>
Date: Sat, 02 Jun 2001 11:13:02 -0700

(Sorry for the previous incomplete message)

Let say that you have to hosts A & B on the same IPv6 subnet, and both host
have another direct connection (e.g. serial link or another ethernet link
at a lower speed) for back-up
Let say that all addresses have global scope. All things being equal,
A and B will resort to longest prefix match. Both prefix being /64,
the algorithm will try to match the other bits. and then... the choice of
the selected link is unpredictable. So depending on the brand and
date of make of the ethernet NIC, communication between A and B
will either take the normal link or the backup link.

My take is that this unpredictability will lead to very difficult to 
diagnose problem.

I would like to suggest to restrict longest prefix match to /64
and,if all things are still equal, apply a predictable algorithm to
choose which address to select. example: always take the prefix
with the highest value. Or best, apply local knowledge when available,
like route metric, interface bandwidth,...
Then, all machines on the same subnet will behave the same way and
network administrator will have less trouble with this.

	 - Alain.

---

From: Alain Durand <[email-masked]>
Date: Sat, 02 Jun 2001 11:23:32 -0700

At 08:59 AM 6/1/2001 -0700, Christian Huitema wrote:
>I believe that Francis has a point when it comes to must vs. should or
>may. The current document is based on theoretical analysis rather than
>field experience, and there is no telling what we will learn in the next
>two years.

I have some sympathy for this argument. This is not so much a problem now to
go to PS, but can be an issue to go to DS.

I have a suggestion here. Split the document in two parts.
One describe the different rules and algorithms,
explain how to compare addresses based on values taken from
various tables, and is published on the standard track.
The other one give the actual values in those tables.
This second document is published as a BCP.

This way, it will be much easier to change the expected behavior if we 
realized,
two years from now, that some of the choices should be reversed.

         - Alain.