Date: Thu, 15 Feb 2001 01:37:57 -0800
From: "Paul Francis" <[EMAIL PROTECTED]>
Message-ID: <000d01c097d9$049d77e0$[EMAIL PROTECTED]>
| Robert Elz also made a good suggestion as to how hosts can learn the
| site-local addresses of other hosts in the site (least-wise it seemed good
| to me). But the state of this suggestion is that it exists in an email and
| nowhere else (i.e., no internet draft),
Yes.
| so unless someone writes it up nothing will happen to it?
I suspect that's true, and yes, it should get made into a draft.
| (By the way Robert, are the ICMP "tell me your
| site local addresses" and ICMP "site local source exiting the site" messages
| you mention in your suggestion in existing drafts, or are these new messages
| you are making up?)
The former is certainly new. I thought that the latter existed already
(and may in the form of destination unreachable code 3), but this is
one which probably deserves an ICMP code of its own (that is: packet
attempting to exit limited scope"). The same thing would be used for
a link local source addr sent to a global address that is of link.
These kinds of packet errors can exist now (without actually provoking
them by suggesting they be used deliberately) can those who have
router implementations indicate what you're using to report the error
when you drop a packet because its source address would not be legal
on the outgoing link? (code 2, "admin prohibited" is another possibility,
but to me that implies more of it being a local policy issue, rather
than a protocol violation).
In any case, any "that packet didn't make it" return would cause the
sending node to skip the site-local and try global. If that also fails
then the host is just unreachable, whatever address is used.
| In the absense of Robert's suggestion or Erik's draft
| (draft-ietf-ipngwg-site-prefixes-05.txt) (both of which require changes to
| existing implementations),
Yes, the difference between the two is that mine only requires changes
to implementations that want to use site-local - so can be phased into
implementations over time. Erik's requires that everyone understand
how to deal with site locals in the DNS before any are added.
| I gather that there are only two possibilities:
|
| 1. Don't use site-local addresses at all.
| 2. Use site-local addresses and two-faced DNS.
|
| Is this a reasonable summary?
I think so. The first is a pretty simple outcome. The second probably
means that only the larger sites, who can afford full time private DNS
maintainers (ie: not outsourcing their DNS to a public server) will be
able to use site-local - which is really the wrong outcome. Site locals
are most needed by the smallest of sites which are most likely to renumber
(like: to use on your home net, in an environment when you get a different
global address every time you dial (or even just every month when you switch
to a cheaper, r less overloaded, provider)).
kre
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
