[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[RRG] Re: [RAM] Different approaches for different protocols
On 20 dec 2007, at 14:05, RJ Atkinson wrote:
Using FQDNs in sockets works fine and is what the world would
have done if pvm had invented DNS *before* BSD invented Sockets.
Right. And then applications wouldn't have to be updated to work with
IPv6 and we'd have had more options to work with in multi6.
Unfortunately, things worked out differently. There are many
applications that still use the old socket API mechanics where the app
is in charge of the name to address mapping.
Further, we do not need a *direct* I->L mapping.
Right again. But this does complicate matters.
I strongly suspect that you are making some (unclear to me)
assumptions
about how an 8+8 scheme works, that are not necessarily true
assumptions
for all 8+8 schemes. O'Dell described a possible 8+8 approach in his
documents. He did not define all possible 8+8 approaches in his
documents. Please think outside the box (or I-D). :-)
You're right, my comments were based directly on the GSE draft.
As I've said many times, if you address the security and deployability
problems in GSE you end up with something that looks a whole lot like
shim6.
I think the only constant for the 8+8 class of solutions is the
fixed split at 8 bytes between the Routing Goop and the Identifier.
I think everything else, including the semantics of both RG and
ID, can vary between one 8+8 scheme and another.
I'd say that the basic idea is the split between id and loc. Having
both in the same packet is GSE and having both be 8 bytes is 8+8. At
some point we were discussing "16+16" where either the id or the loc
is present, not both. Although this complicates some stuff, this is
all stuff that is complicated by the security issue (you can't trust
the loc that the other side supplies with the id) so that's not an
issue and it buys you deployability so it's a net win.
The only advantage a more pure 8+8 approach has over starting an
IPngNG effort is that you get to keep your IPv6 silicon. From the
standardization, software and deployment perspectives this is pretty
much going back 15 years in time and hoping to redo what we did in 5
years but now with better results. I'm sure we can improve some
details here and there, but I don't believe the fundamentals of the
problem have changed so I don't think the outcome will be
fundamentally different, either.
Now, to reiterate a point I try repeatedly to make. I don't think
that 8+8 schemes are the only viable way to proceed. I think they
are one possible way to proceed in IPv6-land. I also think that
we should not race to decide how to proceed in IPv6-land. In
IPv4-land, more haste might be necessary due to current operational
challenges, but there is no need for haste in IPv6-land.
Then again, why waste time on IPv4? Even with routing that scales O(1)
we're never going to have more than 2^32 IPv4 addresses, which isn't
enough to give every person on earth one, while I have currently IP
capable devices in both my pants pockets in addition to the computer
I'm typing this on in front of me. If we assume that the maximum
prefix length on the internet is going to stay at /24 we're not going
to see more than a 6 x increase in the v4 table, anyway. What we
really need is scalable routing while giving users what they want in
IPv6, then we can simply move to that and have some fun coming up with
creative ways to demolish IPv4.
More practically, we should probably stick to working on both IP
versions until such time that this becomes unpractical rather than try
to agree on which IP version is the one that should be addressed
first...
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg