I think the following "rules" should go with this approach:
- Assume DNS returns both PA and PUPI, then if my node only has PUPI, I select the advertised PUPI, if my node has a PA, I select the PA being advertised.
- Obviously, if DNS only returns PUPI and I have both, I use PUPI, and use PA if DNS only returns PA and I have both.
- If there is no match (I have only PUPI and DNS returns PA, or vice versa), I would suggest to fail the connection by default (even though it might work), but I am not sure.
- Referring addresses should only ever be done within type, i.e. never refer a PA over a connection using PUPIs, or vice versa.
Incidentally, this would address quite a few of the scenarios in hain/templin as well as the ones suggested for the ad-hoc cases.
Can the WG move on the Hinden draft, maybe with a set of rules like the ones above (and all the safeguard statements discussed before)?
--On Monday, August 25, 2003 12:11 -0400 Keith Moore <[EMAIL PROTECTED]> wrote:
A lot of these problems are solved if instead of using LL, isolated networks elect a probabistically unique PI prefix (PUPI). I think it would be acceptable to advertise a PUPI in DNS or LLMNR as long as there were no PA addresses available (or maybe as long as any PA addresses were also advertised). And PUPIs are routable by private agreement between managed networks, or within a self-configuring network, so you don't have the same severely constrained use you have with LL.
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] --------------------------------------------------------------------
