Date: Fri, 28 Jun 2002 18:56:57 -0700
From: "Michel Py" <[EMAIL PROTECTED]>
Message-ID:
<[EMAIL PROTECTED]>
| One of the drafts is ready
| http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt
Sorry, "ready" isn't an adjective I'd use to describe that draft.
I've been trying to follow it over the weekend, and the best I've
been able to do so far is to guess at what it is trying to describe.
As best I can tell, this is a rehash of the old idea to separate the
endpoint ID from the address (basically) - that is, there's the stable
ID, which is constant, and the address, which is topology sensitive
(just the same address that we have today). In this version those are
both taken from the same address space (though different chunks of it)
and constrained so that the numbering within a site is identical
(the ID prefix will differ from the address prefix, but the rest of
the bits will always be the same).
Then, rather that simply carry both values in packets, a weird perversion
of NAT is done, which flips from one value to the other in the packets
while in transit.
But I couldn't figure out exactly when that was supposed to happen exactly.
I did understand that it is supposed to be invertible, so the endpoints
don't ever know it happened (removing the worst effect of NAT).
That is, the method described, as best I can understand it (which isn't
much), isn't about geographic (or any other) PI addressing at all, it is
about PI identification, and a method to allow that identification to be
shoved into what is currently defined to be the address field of the packets.
I would strongly suggest that this doc be seriously revised - as a first
step, take what is in section 5, and move it somewhere down nearer the end.
This is the section which contains all of the alternative methods that were
considered but not adopted, and some reasons. While that kind of thing
is valuable to keep, it isn't directly relevant to the protocol being
described, and where it is at the minute, it just gets in the way.
Replace that with a brief, non-technical, overview of the problem that
is being solved, and how the protocol solves it. That is, something like
Multihomed nodes need addresses which do not depend upon
any one of their providers, so packets can reach them over
any available path. This protocol designates identifiers to
be used for that purpose, and details how they are to be
used.
(Here could be a bit about the two different kinds of PI "addressing"
that are being proposed, but I don't think it is necessary).
Then
When a packet is addressed to a PI identifier, it will ...
(and I can't supply any more, as I don't have the vaguest idea how
it is supposed to actually work).
But, in this section, please leave out "alias", "MHAP", and most of
the rest of the stuff that appears in section 6.
After reading this section, people should have a pretty good idea of
what is being done, if not exactly how it all works, and then can
attack section 6, with some kind of idea what all that is in there
is attempting to achieve.
Note, that when this has been explored before, the chief problem has
been security. That is, we rely a lot upon the fact that routing
and identification are tied together, for low level security.
That is, if A receives a packet from B, sends a reply back, and
gets a response to the reply, it can be fairly confident in most
circumstances, that it really is B with which it is communicating.
When using separate IDs for identification, all of that vanishes,
and I don't see anything in your draft to address that problem.
Certainly the security considerations section isn't useful as it is.
It considers one particular problem, and (as best I can tell) offers
as a solution for that "stick a random number in the packet, use that
as a password, so anyone who can snoop it can do what they like".
Of course, that might just be me failing to understand how any of
this is intended to work.
| Feel free to ask any questions you wish on ipv6mh.
Sorry, I've forgotten where that list is, and I'm too busy/lazy
at the minute to go hunting - if you want to move the discussion
to some other place, give the complete address...
| > The aim is a /48 for everyone (who requests one), right?
|
| At this point the aim is at multihomers only.
That isn't exactly what I was referring to - the "/48 to everyone"
was meant as a general reference - that is, all sites (large and
small) receive /48 allocations (from somewhere), always, if they
want one (that isn't to say that a single host can't just be given
a /128 if that's all it requests .. in fact, the vast majority of
hosts on the vast majority of networks will get exactly that).
However, if you succeed in creating a PI address space that is available,
you can be sure that it will be used by *everybody*. Pretending that
only some subset of the internet will desire one of these PI addresses,
or that there's any way to restrict their use is silly. Were you to
try, I can see a nice business for someone as a "multihoming provider",
who offers prefixes to people, but provides no connectivity at all, but
with every appearance of being an alternate point of connectivity from
the outside (one that just happens to be down a lot when people attempt
to test it...). Then of course, once the PI address is obtained, the
contract with that provider will be allowed to lapse - it isn't needed
for anything any more.
Your scheme is even worse than that though, as you have two types of PI
addresses, geographic (which ties people to one area) and the other kind
"for large multi-nationals". The latter is the kind I'll be applying
for for my laptop, after all, it is multi-national (connects to the net
in lots of different nations), and I am large...
The draft claims that it solves scaling by reducing the size of the tables
by a factor of 100 (which seems to come from nowhere, but for now let's
just accept it). Sorry - linear factor reductions are useless for this
purpose, even large ones. Exponential growth, divided by 100, is still
exponential growth. To solve the scaling problems, you need to do something
to change the exponential growth, to at least linear, and preferably
less than that.
Before I finish, in the revised draft, you will also need to say a lot more
about the "local aggregation authority" - where it comes from, what it
does, etc. At one point the draft suggests that it could be "one of the
ISPs", but with no suggestion on how that ISP is selected, or what it means
to be the one who is blessed (or not to be). This is another area that
needs lots of work, as creating lots of new authorities, without some
method for determining just who they are, and how they are controlled, is
a sure recipe for disaster.
| > It isn't possible to enforce anything by relying upon protocols,
| > we have to depend upon agreements, and when appropriate "it is
| > the only possible way".
|
| I have to disagree with this. If by _design_ these geo prefixes are not
| in the global routing table, the only leaks could be because of
| configuration snafus.
Huh? All prefixes are just numbers. They're all being taken from the
same number space. How can they possibly "by design" not all fit in the
same routing table. You're relying on people filtering these particular
numbers, which they will do, only while there some incentive to do that,
and no incentive to do otherwise.
kre
ps: I am still looking for a proposal that uses geographic *addresses*
and can work without connectivity/transit requirements being imposed upon
the ISPs that claim to offer service in that geographic area.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
