Subject: (IPng 6858) Re: Site prefixes?

From: "Matt Crawford" <[email-masked]>
Date: Sun, 06 Dec 1998 18:24:47 -0600

I found a quiet moment to read site-prefixes carefully and have
a few comments.  Several are just nits.

Sec. 1, para 3 - I'd rather you said "cost of renumbering" than "risk",
just for PR's sake.  And in the next para, I think the first intra
should have been an inter.

What about a dual-sited node that does not have any SL addresses in 
one of the sites, but does in the other, but "the other" site does
contain some nodes that do have SL addresses?  This should be common
for a mobile node in its visited site.  Then nodes in that site with
SL addresses won't be able to reach that dual-sited node.

Sec 3.2, there's a repeated "the binding updates", and 6 non-blank lines
further down a missing "is".  Later in that section I think replacing
"the specification" with "this specification" would be clearer.

Sec 4, moving the SitePLength field over to the right might make
the update of router renumbering cleaner, should this come about.

At the very end of section 5 you might mention an "unless": if for
some inscrutable reason the "site" lifetime needs to be different
from the regular ND lifetime.

Sec 7., "do nothing further" would be more exact than "ignore the prefix",
which could be construed by some perverse minds to mean back up and undo
regular ND stuff.  And in the second bullet point, shouldn't that be
"*a* link-local or *a* site-local", rather than *the*?

At the end of the processing in sec. 7 it might be handier to
copy the timer value from the regular ND setting, to which the DOS
timer defense has already been applied, if the current PIO is
valid for both purposes.  But that's not vital, since the consequences
of dropping a site prefix are much less.

Sec 8.1, processing step 3.  I think you should return the set of
SL addresses *and* those Gi's which didn't match any locally-known
site prefix.

However, that last remark does nothing to correct the defect which
noted in my second point.  That's a bit of a head-scratcher.

			Matt

--------------------------------------------------------------------
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: Thu, 10 Dec 1998 13:02:07 -0800 (PST)

Thanks for the careful reading - I've applied all the editorial comments.

> just for PR's sake.

I could do that but I was trying to somewhat distiguish between the effort
of renumbering (updating DNS, reconfiguring routers etc) with the risk
associated with things that you can't track down in advance (such as
applications having cached IP addresses in memory or in files).

Do you think that distinction makes sense?

> SL addresses won't be able to reach that dual-sited node.

That it only true of the nodes in "the other" site do not have any
global addresses. And if they don't have global addresses they can't
communicate with the mobile when it is at home. So I guess I don't see the
problem.

> "the specification" with "this specification" would be clearer.

I don't find the missing "is" - there is some complex sentence that I can
rephrase.

> the update of router renumbering cleaner, should this come about.

I'll do that.

> of dropping a site prefix are much less.

I don't think addrconf says anything other than the 2 hour rules for
the valid lifetime for addrconf purposes. For instance, I've interpreted
it to NOT apply to the "onlink" property of the same prefix.
If we want to mandate that the 2 hour rules apply to site-prefixes
then I think we must also mandate the rule for the on-link part (i.e.
revise the ND spec.)

I don't see a bug in leaving this with minimal specification.

> SL addresses *and* those Gi's which didn't match any locally-known

Yes, that would make sense. That way if the peer is multihomed with some
interfaces in "your" site and some outside it ensures that the application
can try reaching all of its interfaces while using site-local addresses
to use the interfaces local to the site.

   Erik

---

From: Brian Haberman <[email-masked]>
Date: Fri, 11 Dec 1998 07:51:23 -0500

Erik,

> Do you think that distinction makes sense?

The previous sentence makes the point about stored IP addresses
potentially
causing problems, so I don't see a reason not to make the change Matt
suggested.

> communicate with the mobile when it is at home. So I guess I don't see the

I don't see a problem either.  This type of scenario has been pointed
out in
the scoped-address routing draft as well.  I believe the solution is in
the
routing draft.

Here are a few other comments, questions.  A question about the
assumption
made in Sec. 3.3, paragraph 2.  What if some subnet within a site does
not
have any global addresses?  The simple solution is that the subnet ID
field
is set to a value not in use as a Site-Local Aggregator.  Should this be
mentioned?

In Sec. 4, the Site PLength is allowed to have a value between 0 and
128,
inclusive.  Is 0 a valid site prefix length?

Brian Haberman

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 14 Dec 1998 11:51:42 -0800 (PST)

> is set to a value not in use as a Site-Local Aggregator.  Should this be

I'll expand on this.
In fact, all you need is only configure (on the nodes and in DNS) 
the site-local addresses for those subnets. 

> inclusive.  Is 0 a valid site prefix length?

I see no reason to have a lower limit on the length of site prefixes
since ND doesn't have a lower limit on the length of subnet prefixes.
(What number other than zero would make sense since we don't know
what future addressing plans might look like?)

   Erik