There is one known problem in the draft that kre discovered.
The tweak to the rules to allow an isolated site to work causes problems.
The rules say that if the RRset only contains site-local addresses
then the RRset is accepted as is i.e. the site-local addresses
are used.
This causes problems if there are hosts in connected sites which only
list site-local addresses in the DNS.
For instance, if you have a node in site A which never communicates outside
site A it would list one (or more) site-local addresses in the global DNS.
The above rule would make all hosts in the internet assume that the
host in site A is in fact in their own site.
A possible way to fix this is to 1) remove the special rule 2 in
section 8.1 and 2) configure the routers to send a site-prefix of fec0::/10
if and only if the site is isolated.
(This also implies adding some special rules for the semantics of
fec0::0/10 being advertised as a site-prefix.)
But, ...
kre also pointed out that it would be cleaner to not store the site-local
addresses in the DNS but instead have a mechanism to discover them using
e.g. the ICMP name lookups exchanges.
It would be good to flush out such a proposal and compare it with what is
currently in site-prefixes-05.
This is a rough straw-man of how such a proposal would work.
1. Only global addresses are stored in DNS.
2. A mechanism (such as the prefix advertisements in site-prefix-05)
is used to provide a hint of which global addresses are in the same site.
3. When the hint indicates that an address is in the same site a
message exchange is used to verify site-local connectivity and retrieve
the peer's site-local address.
This can be done by sending an ICMP name lookup with a site-local
source address asking for the site-local address(es) of the peer.
If there is a reply to the ICMP name lookup site-local communication
is possible (since the source of the query was a site-local address)
And if the ICMP name lookup returns a site-local address, that address
can be used when communicating with the peer.
Pro's of such a scheme:
- no need to have site-local addresses in the DNS - smaller DNS replies
- no transition problem due to nodes accidentally using site-local
addresses returned from the DNS without implementing the rules
in site-prefixes-05.txt
Cons
- additional roundtrip to discover site-local addresses.
- if the ICMP name lookup fails (after timeout and retransmit)
due to temporary failures then communication within a site would use
global addresses. Such communication would not be isolated from
site renumbering events.
- the implementation (getaddrinfo?) would need some code to send
the icmp name lookup packets and wait for replies.
Same as site-prefix-05.txt
- a mobile node can choose whether or not it will have a site-local address
or just global addresses.
Open issues for such a scheme:
- assuming DNS is secured using DNSsec, how do we easily get the same
security for the site-local address(es) returned by ICMP name lookup?
- if the peer has multiple global addresses should an ICMP name lookup
be sent to each global address that is part of the site?
Some NICs on the peer might have failed thus sending to all seems more
robust.
Does anybody want to flush out the details of such a scheme?
Or should we try to do this in Minneapolis?
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 PROTECTED]
--------------------------------------------------------------------
