Subject: draft-ietf-ipngwg-site-prefixes-05.txt

From: [email-masked]
Date: Tue, 6 Mar 2001 13:08:51 -0600

Erik,

Hi Erik,

This is looking good.  I like the middle ground you adopted.  Need to read
again to check the Mobile node implications.
I don't see away around it but I hate to see us encapsulate yet another new
protocol for COA in MIPv6.  I might suggest some wording in this spec that
using Global Addresses avoids all the management and performance costs in
the router (HA) if a mobile node at home using site-local address when
moving gets a Global address and sends binding updates to all before it
leaves home.  This type of policy will benefit greatly operation of MIPv6
IMO.

But the draft looks good.

Seems like you should be on the IPng agenda.   If we nail down:

  scope-arch
  near-unique-sitelocal-addresses
  your site prefix draft
  src addr selection

We will have enough as implementors to begin adding robust scoping to the
code base to support this in the IPv6 architecture.

regards,
/jim
--------------------------------------------------------------------
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: Erik Nordmark <[email-masked]>
Date: Wed, 7 Mar 2001 11:08:26 +0100 (CET)

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