Subject: Source address selection draft

From: Alain Durand <[email-masked]>
Date: Wed, 03 Oct 2001 10:25:47 -0700

I missed this part of the IPng discussion on source address selection/
destination address ordering.

There were two points I would have like to make:

1- Some of this text is clearly in the scope of standard track.
     e.g. deprecated vs non deprecated
     Some other parts are more questionable, are would better
     fit in a Best Current Practise (BCP) document.
     e.g privacy extension, 6to4, other non-native addresses....
     We have recently discovered some issues with ISATAP
     that ended up in modified text in the draft. I'm sure such
     other similar problems will be discovered in the future.
     It will be much easier to reissue the BCP part than
     to modify the complete RFC if it ever reach DS status.

    So I would have like to re-iterate my suggestion to split
    the document in two:
      framework, obvious rules... goes standard track
      other rules, values in various tables goes BCP

2. The current draft does longest prefix match on 128 bits.
     In the case of a dual-rail network where each hosts has
     2 interfaces

     prefix P1/64
     ------------------------------------------------------
           | h1                  | h2               |h3
     ------------------------------------------------------
     prefix P2/64

     In this case, the choice of network 1 or network 2 depend
     on the actual MAC address of the hosts.
     This is a situation that is very difficult to understand/debug
     by network administrator.

     I would like to suggest to do longest prefix match only on the 64 most 
significant bits.

	- Alain. 

--------------------------------------------------------------------
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: "Richard Draves" <[email-masked]>
Date: Fri, 5 Oct 2001 15:40:33 -0700

> I missed this part of the IPng discussion on source address 
> selection/ destination address ordering.
> 

I think it would be rather awkward to have the specification split into
two documents. Part of the problem with the current situation is that
the information and rules for different kinds of addresses(deprecated vs
non-deprecated, scoping, temporary addresses, native vs transition
addresses, etc, etc) is spread across many documents and it is not
obvious how to handle conflicting requirements. The relative priority of
the different requirements is not clear when the specification is broken
up into pieces.

When someone invents a new kind of address a year from now, then their
specification can say how it should be handled (modify Rule N as
follows, or insert rule N.5 between rule N and N+1) wrt the standard
framework for address selection. And at some point "Default Address
Selection v2" can collect up any changes & improvements and progress as
an upgrade to the original standard. The original Default Address
Selection might make it to DS while the v2 version could be cycled at
draft or PS.

>      In the case of a dual-rail network where each hosts has

See my previous email.

Thanks,
Rich

---

From: Bob Hinden <[email-masked]>
Date: Mon, 08 Oct 2001 14:33:30 -0700

I would like to add that at the London IETF meeting the majority of the 
discussion on this draft was on this issue (i.e., whether to split the 
source address selection document into two documents).  At the end of the 
discussion, there was a general consensus to not split the document as 
doing so would harm interoperability.  This was captured in the minutes for 
the meeting.

Bob