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