Date: Wed, 19 Jun 2002 11:07:10 -0400
From: Keith Moore <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| but it depends to some degree on how LL is pitched to the public.
Yes, exactly - and one of its planned uses (right from day 1) was to
support "dentist office" networks - perhaps more likely these days
as "IETF attendees on a bus" (not a plane as using 802.11 there is
probably frowned upon, I haven't risked trying it to see if anyone
would notice...) who just happen to create an ad-hoc network, with
no external support at all.
| I don't think use of LL by apps is a good idea for either v4 or v6.
To eliminate this completely, you need to find a way to assign a global
address with no delay (no more than a minute anyway) and no network
connectivity required to obtain it. I think that means a well known
prefix - which is exactly what the SL prefix is. So if you really
want to prevent this usage of LL's, I think you not only have to support
SL addresses - but actually make implementation of them mandatory.
I'd just keep SL support optional (require as little as possible) and
have the apps deal with LL addresses when the situation arises.
| the danger is that SL addrs are clearly meant for use by apps, while
| it can be argued that LLs aren't meant for GP use.
You could try arguing that, but you'd be arguing against the design.
| ISPs that pull that kind of stunt deserve to go out of business quickly.
Unfortunately, that requires the customers to desert, quickly, which requires
yet another renumbering.
And remember, that while an ISP could do this as a stunt, the more likely
cause is going to be the network (via a nanog or similar meeting) deciding
that the routing table is simply getting too big, too fast, and that some
realigning of addresses is required to allow topological aggregation to
work again with the network configured in the state that it has developed
into at the time.
That is, it isn't a "stunt". And while you can argue that such a
change should be properly planned, my counter is that no amount of
proper planning is sufficient - I want connections to be able to
exist where the address will *never* change (other than at my specific
demand - no-one else can ever instigate it).
| to some degree this is govered by public perception about what is
| reasonable, and such perception can be influenced by standards.
| so we do have some influence here. we should try to use it.
Yes. To do that in an honest way, we first need to decide how to
avoid requiring addresses with either topological or geographical
significance (both of which require renumbering sometimes).
The original (70's-80's) IP allocation scheme would be OK (allocate
1 2 3 4 ... to however asks in the order they ask). Just make routing
work with that. Or, propose something else.
| there's no way to absolutely
| prevent brain-damage like unannounced renumbering,
I am not worried about unannounced renumbering, but *any* renumbering.
Announced 5 years in advance or not...
| easiest way to fix this is to have NFS (and those other apps) use mobile IP.
Doesn't work. That requires a stable address to use as the home agent.
And if the net has been renumbered, the stable address doesn't work.
If we had designed good EIDs instead of just having addresses, then mobile
IP would have been almost a no-brainer. (And so would renumbering,
mobile-IP then just treated as one reason for renumbering).
But we didn't, and now mobile-IP depends upon stable addresses just like
everything else (it trades off one stable address for another).
| I don't think it flies as long as we're requiring sites to connect
| to the public net to get global addresses, and some sites don't want to
| connect to the public net at all.
Hmm - maybe I'm not being clear, or you just missed my point. No
requirement for a site to connect to the public net, certainly.
A site that isn't connected just uses SL addresses as if they were
global addresses (they go in its disconnected DNS - or however it does
address lookups) and are used exactly like anyone else would use a
global address. The site boundaries are the ends of the net as we
know it, so there's no magic at all here.
To allow two disconnected sites to communicate, they need either
global addresses (in which case they're just becoming another internet
and as many sites as like, and are permitted, can connect to that, instead
of the public net) or we need some kind of site ID in SL addresses
(and in the latter case, they just go on acting as if they were global,
in the former, SL's are the same as SL's on the public net, and there
is a global address to use to make the SL's work).
Groups of sites, talking to each other, but disconnected from the "one
true internet" is something that the current addressing plans really
haven't allowed for, and should.
| with global non-routable addresses, the site-id is carried along with the
| address, it's exposed as part of the address (assuming a reserved prefix
| for such addresses), it's returned in the same kind of DNS RR that carries
| a normal address. the address is globally scoped so there is no chance
| of mistaking an address from a remote site as being one from a local site
| or a different remote site.
But there's no way to tell from the address that it is one that you
cannot reach from outside, which makes it annoying (at best) to pass
around.
Of course, we could have such addresses marked by a magic prefix, that
people could recognise. Then there'd be no problem. And of course, that
is exactly what a SL address with a site-id in it is. (Note: I think
I'm one of comparatively few people who actually support site-id's in
SL addresses).
| again, I don't think that flies. too many enterprise nets are not
| connected to the public internet have no way to get globals.
| in the current IPv6 view, they have no way to get global IPv6 addresses .
See above.
| even if they borrow a prefix from somewhere, those addresses won't
| really be global in the sense that they're reachable from elsewhere.
If the site is not connected, then "reachable from elsewhere" is a
pretty meaningless concept. If a "borrowed" prefix is what it takes
to make things work in some rare cases, then that's exactly what
people will do. If renumbering out of it into a "proper" address is
not too hard or disruptive, then they will do that too when they connect.
But borrowed or a true advertised topological global address, wouldn't
matter (in the very rare case that such a thing would be needed).
| But it seems to me that if we do have these, we don't need SL anymore.
We don't need SL with the bit pattern that we have, but non-routable
global addresses would just be the same thing for most purposes (just
avoid the scope issue in the API etc). So would SL's with site-id's.
| perhaps (and I probably agree), but right now we're insisting on just
| the opposite.
You mean in IPv4? Yes, that need to be corrected. If you meant
IPv6, then I don't understand what you're trying to say.
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]
--------------------------------------------------------------------
