I would like to inject a suggestion into the current SL replacement debate. (Note that this is not my original idea, just something that I know the group started to discuss and then dropped -- it might be good to pick up again now).

We have a trio of drafts that I fully believe can be polished into a combination "deprecate SLs" and "here is how to handle special cases that require local addressing". We have also restarted a spirited debate best titled "SLs die.die.die".

In looking for clues (or clue), I found:

Love H�rnquist �strand:
Please, just let SL die, as an application programmer, I
find SL to be a mistake as currently designed.

Keith Moore had a similar comment; I have lost the extact quote.


Andrew White:
Unless we allow only one address per node an application writer MUST
assume that any
arbitrary source-destination pair may fail while another may succeed.

Alain Durand:
IMHO, what need to happen is the following:

-1. Make an in-depth study of the consequences of introducing
     addresses with different ranges.


and in draft-hain-templin-ipv6-limitedrange-00.txt
  In the simple case, hosts that are allowed external access have a
  policy that allows them to configure both global and limited range
  prefixes, while those that are not allowed global access have a
  policy that only allows limited range. ***Address selection rules will
  prefer the smallest range***, so internal communications are forced to
  stay internal by the hard filter at the border.

(Emphasis added by me).

draft-hain-templin-ipv6-limitedrange-00 does a good job outlining scenarios that may require the use of local addressing, but I think it errs in the statement above. The local addressing requirement is real enough, but these are still corner cases. Aside from ambiguity, enforcing the concept of scope or range _in every application_ seems to be one that folks really want to get rid of.

Hence, lets revisit the question of _default_ address selection. What if:

"Unless an application explicitly requests otherwise, an IPv6 node must use its unique, globally routable address if one is configured. If no such address is configured, the node shall use its limited range local address, if configured."

Along with:

"An IPv6 node must allow an application to explicitly request the use of the limited range local address, if such an address has been configured, even if a unique globally routable address is available."

What I am trying to get to is:

- Application designers who want to work in the "end-to-end clean" Internet and who do not care to support the corner cases should be able to do so.

- The default address selection rules should favor solutions based on global addressing, I think we all agree that if such a solution is reasonably possible, it should be used. With the defaults above, the "path of least resistance" is not to use limited range, which is good.

- Finally, if a solution requires local addressing, and application writers want to support it, there needs to be a standardized way to do this (which is why local addresses must be defined and recognizable).

In draft-hain-templin-ipv6-limitedrange-00, scenarios where all machines either have only local addresses, or where all of them (albeit intermittently) acquire global addresses along with the local ones, will work with the default behaviour suggested above.

Cases where networks contain a mixture of nodes (some local only, some local and global), and very long-lived connections in intermittently connected networks, need special handling. In both cases it seems reasonable that applications will be written or at least configured to be aware of the local/global address issue.

Along with safeguards against address translation in the nodes requirement, and routing restrictions in the address format document, this should work.

I know I left out plenty of detail, but I hope the general idea is clear enough. Comment/Flame away.....




Hans Kruse, Associate Professor J. Warren McClure School of Communication Systems Management Adjunct Associate Professor of Electrical Engineering and Computer Science Ohio University, Athens, OH, 45701 740-593-4891 voice, 740-593-4889 fax

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