[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Identifier (structure) [Was: Agenda for Vienna]

On dinsdag, mei 20, 2003, at 18:41 Europe/Amsterdam, marcelo bagnulo wrote:

Yes, that is one approach.
It might make it more difficult for transition schemes where an unmodified
IPv6 host plus some "proxy" e.g. at the site border together implement things.
In such a case I think the IPv6 host (for transition purposes) would
send packets where IP source and destination are identifiers
thus the "proxy" would not see such higher level "real" identifiers.
When a proxy is used the identifiers must take the shape of valid IPv6 unicast addresses (or possibly IPv4 addresses). Host implementations could use any identifier they like, except that this means changing the TCP and UDP checksum calculations. So IPv6 addresses will probably be the most important identifier category for some time to come, but if we do this right we finally get to disconnect the network and transport layers so we can change the network layer protocol without too much trouble the next time around.

Another issue to consider in this space is the goal to allow
applications already ported to IPv6 to continue to work when
the application uses getaddrinfo() followed by connect()/sendto().
This is at least easier to accomplish if the identifier fits in 128 bits.


Do you think that the identifier name space should be the same that the
locator address space or should be a separate one?





I mean, we could use the IPv6 address space to contain both locators 
and

identifiers and that any address could be used both as an identifier or

as locator.




The other option is to split the IPv6 address space and reserve a part
of it to identifiers




There are advantages to both having a separate identifier space and to 
being able to make each IPv6 address an identifier. Hard to say which 
way we should go here.




Finally, we could use a completely separate 128 bit address space




Well, I argued in favor of having different kinds of identifiers so 
non-IPv6 128 bit identifiers would be one type. However, adopting these 
has the downside that you must always implicitly or explicitly know 
whether you're talking about an identifier or a locator, and since 
current implementations don't know about this that's going to be hard. 
Having the option of looking at an address or looking up an address and 
then see if it's a locator, an identifier or possibly both makes things 
easier.



In another message you write:




to my understanding multiple of the above solutions are based on the
loc/id separation





That is:
- mobility
- HIP
- address agile transports
- loc/id





Are solutions based on the separation of loc/id roles. I mean all of
them use a fixed identifier for application layer and multiple locators
for routing (in this case in the end -hosts)




Careful here: not everything that uses more than one address separates 
the locator and identifier functions. Address agile transports simply 
use multiple addresses that overload the loc+id functions the same way 
single addresses do in TCP and UDP. MIP uses the loc+id for the home 
address and just the loc for the care of address. But I'd prefer to not 
categorize MIP as a loc/id variant because it doesn't really address 
this issue (as far as I know, that draft is REALLY long).



By the way, does anyone know if MIPv6 and routing optimization are 
supported widely yet? I seem to remember this was "mandatory" but as 
far as I can tell the stuff I work with doesn't support this or at 
least doesn't say it supports it.



HIP may in fact incorporate a locator/identifier separation but it does 
so much more and is by its nature not suitable as a general multihoming 
solution so I don't want to count it as loc/id either.




A really good approach to this issue is JNC's Endpoint and endpoint
names (can be found http://users.exis.net/~jnc/tech/endpoints.txt) for
those few of you who has not read it yet :-)




Yes, this is good stuff. The NSRG report was interesting too but a few 
too many open doors. Great the way they start the security 
considerations section on page 2, though.  :-)



One comment on the endpoint thing: this brings up the interesting 
question whether we care about the nature of the item being identified 
by an identifier. Does it matter whether an identifier points to a 
host, a process, a service or an interface? Those have different 
properties, but each may act as an endpoint at some point in time.