Subject: RE: draft-ietf-ipngwg-site-prefixes

From: Richard Draves <[email-masked]>
Date: Mon, 13 Dec 1999 22:03:37 -0800

> > Should there be a validation for S-bit processing of Prefix 
> Information
> > Options that the site prefix length is <= prefix length?
> 
> Well, if neither the L or the A bit are set then Prefix 
> Length doesn't make
> sense. Thus the check would be a bit complex.
> And it seems better to keep things orthogonal.

OK.

> > In section 8.1 - I'd rather keep both site-local and global 
> addresses in the
> > returned address list and let the destination address 
> ordering algorithm
> > apply.
> 
> The disadvantage of doing that is that you can't ensure that 
> site-local
> communication uses site-local addresses. For instance if a 
> router is broken
> when the application tries to connect the application might 
> fail to connect
> using the site-local address. When it tries to connect using 
> the global
> address the router might be back up.

If for some reason the site-local address is not working but the global
address does, won't it almost always be better to use the global address?
Using the global address will only be a problem if there is a renumbering or
some other event that effects the global prefix. So it seems best to risk a
small chance of a future failure to prevent otherwise certain failure in the
present.

> > I think there needs to be more in section 8.1 about site 
> scope-ids. When a
> > site-local address is returned it needs a site scope-id 
> value. I think this
> > can be derived by keeping track of what interface learned what Site
> > Prefixes, and using the site scope-id value associated with 
> the interface of
> > the relevant Site Prefix.
> 
> Hmm - I wonder if this is the right document to wander into 
> API land which
> is where scope-ids appear.
> Perhaps it can be phrased without using the term scope id.
> Something along the lines of
> 	In multi-sited nodes the site-local addresses need to 
> be associated
> 	with the set of interfaces that are connected to a site.
> 	[Some APIs do this using a scope-id concept - see XXX]
> 	This identification can be done by tracking the 
> interface for which
> 	the site prefix matched in step 3) and use that interface
> 	to determine the associated attached site.

Well, the document already has a toe into API land because it's effectively
talking about what getaddrinfo/getipnodebyname implementations should do.
Keeping the phrasing less API-specific would be good but something is
needed.

> > It was enough code that I think it should be optional. So 
> allow simple
> > implementations, when looking at an address list with both 
> site-local and
> > global addresses, to just remove the site-local addresses 
> without keeping
> > track of Site Prefixes.
> 
> Sorry, what was enough code? 
> 
> Yes, simple implementations might want to
> ignore site-local addresses unless the RRset contains only site-local
> addresses i.e. the case when the site is not connected to the 
> Internet.

The code to maintain and use the Site Prefix Table, allow for the new type
of Prefix Information option when sending & receiving RAs, etc. It was
probably 100-200 lines of code (guesstimate).

Rich
--------------------------------------------------------------------
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: Tue, 14 Dec 1999 09:35:08 -0800 (PST)

> small chance of a future failure to prevent otherwise certain failure in the

I don't know.
It has to do with the users' perception of the viability of site renumbering.
If we can make a statement that says "if you configure things this way
then all site-internal communication will be unaffected by site renumbering
since it will always of site-local addresses" would that be helpful in
convincing users that the risks associated with planned renumbering (with
overlap when both prefixes are valid) are acceptable?

Or will the users' perception be that an IPv6-IPv6 NAT box is the best way
to deal with site renumbering. (I hope not.)

Or is exchange based addresses the way to avoid this all together when
switching ISPs? Will such addresses come into use? How will the users be
educated so that they can ask their ISPs for exchange based IPv6 addresses?

> Keeping the phrasing less API-specific would be good but something is

Will do.

  Erik