Subject: RE: Agenda for Vienna

From: "Tony Li" <[email-masked]>
Date: Wed, 14 May 2003 15:56:12 -0700

I'd like to take this opportunity to again ask that we put aside
our petty and trivial differences, the implementation foibles
and our particular pet proposals (mine included).  Instead
we should take this time to sit down and have a collaborative
architectural discussion.  

It is the perogative and responsibility of the chairs to 
ensure that we make forward progress and I call on them to
step up, lead the discussion, and ensure that we stay at
a civilized and architectural level.

Once we have an architecture for a solution, THEN we can
start worrying about the bits.

This implies that we should not be looking at particular
proposals.  We should not even be looking at 'categories'
of proposals.  Instead, we should be talking about possible
architectures.  That's one layer farther up.

Regards,
Tony

|    -----Original Message-----
|    From: Kurt Erik Lindqvist [mailto:[email-masked]] 
|    Sent: Wednesday, May 14, 2003 8:04 AM
|    To: [email-masked]
|    Subject: Agenda for Vienna
|    
|    
|    
|    Ok, so me, Sean and Randy have been discussing a possible 
|    agenda for 
|    Vienna. We tried to incorporate as much of the views as 
|    possible. Our 
|    suggestion is as follows :
|    
|    
|    1. We schedule two sessions.
|    
|    2. The first session is early in the week, and have one topic. The 
|    proposals that have then been made formally to the IETF 
|    will each get 
|    around five minutes. Each presenter will be a member of a 
|    "panel". The 
|    working-group and the other presenters are allowed to ask 
|    questions on 
|    the proposals and try and better understand the proposals.
|    
|    3. The second session will be scheduled later in the week. 
|    This will 
|    concentrate on the two main proposals that are currently 
|    being worked 
|    on. Those being loc/id which seems to be the main one, and 
|    host based 
|    solutions. This session would be started off with an 
|    overview of the 
|    status on this, and perhaps a summary of the earlier session.
|    
|    So to elaborate a bit. The first session is not meant to 
|    be a "survivor 
|    wins" session; and that will put some work on the chairs. It's 
|    intention is to give a clearer picture of the proposals. The main 
|    reason for the first session would be to allow discussions 
|    around the 
|    proposals in the hallways, leading up to the next session 
|    (so we will 
|    try and have a few days in between). The first session is 
|    also not mean 
|    to be q "qualifying" session for the second one. To me 
|    (and from what I 
|    read on the list - most others) it is very clear that 
|    there is only two 
|    real solutions being worked on at the moment. I also want 
|    to point out 
|    that the WG sessions are not there for a full presentation of the 
|    proposals - You are supposed to read the drafts :-) ; 
|    which means that 
|    you need to submit the drafts. As for members of the 
|    panel, I would 
|    personally not want to see several similar proposals being 
|    presented, 
|    but there aren't that many out there anyway so this should 
|    not be an 
|    issue.
|    
|    The second session is meant to be an opportunity to dig 
|    more into what 
|    we think are required of each of the solutions; what the 
|    issues are; 
|    ways forward. As has been said a number of times on this 
|    list by Vienna 
|    we need to have a lot of basic issues sorted out by Vienna.
|    
|    As I see it at the moment I would schedule 1h for the 
|    first session and 
|    2h for the second one.
|    
|    Last, I guess one of the questions will be "why the first 
|    session?". 
|    The intent is only that a better understanding of other 
|    proposals will 
|    help us with more ideas. I don't see the main track 
|    changing unless all 
|    of a sudden a large part of the working group change their minds.
|    
|    I will leave this a few days for comments and then go 
|    ahead and make 
|    the request to the secretariat. We would like to do this 
|    as quick as 
|    possible though. And I hope that there isn't to many 
|    issues with this 
|    proposal.
|    
|    Best regards,
|    
|    - kurtis -
|    
|    
|

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 15 May 2003 09:54:49 +0200

> architectural discussion.

It's not always easy to see where architecture ends and interior 
decorating begins.

Some notions that seem relatively undisputed:

- we separate the identifier and locator functions so we can have 
multiple locators and still have a single identifier
- IP in transit works with locators, everything above the IP layer with 
the identifier

This leads to the following questions:

- what should identifiers look like?
- assuming applications use identifiers, how do we know which locators 
go with a certain identifier?
- when receiving packets, how do we know (= better than take her word 
for it) the correspondent's identifier?

Then there is the address selection problem. We know that the current 
"pick one and die if it doesn't work" approach is no good so we have to 
come up with something better.

The draft I wrote on sunday uses a minimalist approach to answer all 
these questions (well except the source address selection thing). It 
would be good to have one or more different sets of answers written up 
in enough detail to be able to determine which approach is preferable. 
Waiting for Vienna and trying to do it there in two hours isn't going 
to work well IMO.

---

From: Kurt Erik Lindqvist <[email-masked]>
Date: Thu, 15 May 2003 11:58:48 +0200

Tony,

> architectural discussion.

Agreed.

> architectures.  That's one layer farther up.

The idea with doing the agenda the way we have proposed is to try and 
have the best of both worlds. The idea is that the second session is 
just this. Sit down and try and work out the architectural principles. 
The first session is not necessarily  intended to influence this 
discussion (again, the first session is not the qualifying session for 
the second). See the first session as a "marketing" (for the lack of 
better word) event for multi6.

It's not ideal, but we are trying to a) Give people the opportunity to 
express their thoughts on the architecture (although with detailed 
examples) and b) Have a discussion on the future architecture.

Best regards,

- kurtis -

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 15 May 2003 12:04:05 +0200

Tony Li wrote:
...
> architectures.  That's one layer farther up.

This is *very* important. In the proposed second session, please
let us concentrate on the architectural model of each of the
two solution classes you want to explore.

For example, whether we achieve identifier/locator separation
by encapsulation, rewriting, 2-addresses-in-1-header, or
2-halves-in-1-address should be an implementation detail in
the first level of discussion.

Tony Li also wrote:

> |    Some notions that seem relatively undisputed:
> |    
> |    - we separate the identifier and locator functions so we can have 
> |    multiple locators and still have a single identifier
> |    - IP in transit works with locators, everything above the 
> |    IP layer with 
> |    the identifier
> |    
> 
> Do we really have consensus on these points?  Does this imply that
> tunneling is no longer a consideration?

As I just said, I don't think that follows. Map-and-encap is just an
implementation of id/loc separation, viewed from high enough.

   Brian

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 15 May 2003 19:14:27 +0859 ()

Brian;

> two solution classes you want to explore.

My draft draft-ohta-e2e-multihoming-03.txt:

               The Architecture of End to End Multihoming

discusses, as is obvious from its title, architectural issue on
host based approach. It, of course, mention loc/id separation.

> the first level of discussion.

That's rather an implementation detail than an architecural
issue.

The more important architecural issue is which part of the Internet
protocol suits must/should/may be affected.

In my draft, I, so far, have identified, IP, TCP, non-TCP applications,
DNS and IGP.

						Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 15 May 2003 12:59:31 +0200

On donderdag, mei 15, 2003, at 12:15 Europe/Amsterdam, Masataka Ohta 

> host based approach. It, of course, mention loc/id separation.

In this draft you say TCP (and other protocols, leaving those alone for 
a moment) should get multiple addresses from the application. This is 
what SCTP already does. I don't see how this is separating the locator 
and identifier functions, it's just more instances of the combined 
locator/identifier we're used to.

I feel this approach isn't a good one both for architectural reasons 
and for deployment reasons (this simply needs too many changes to too 
many things). The current architecture doesn't differentiate between 
identifiers and locators so it imposes limits on one because of the 
requirements for the other. This is messy. Having more of those 
combined locator/identifier addresses just increases the mess linearly. 
On the other hand, separating the identifier and locator functions 
makes it possible to have both the advantages of a stable identifier 
and the advantages of flexible locators.

However, I do agree that TCP knows much more about reachability than IP 
so in practice we'll want to take advantage of that. But there are 
other ways to skin this particular cat than selecting layer 4 as the 
place to solve the multihoming problem.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 15 May 2003 21:01:32 +0859 ()

Iljitsch;

> a moment) should get multiple addresses from the application.

Well, basically, I say hosts should have multiple addresses. It is,
of course, at IP layer.

Protocols above IP are, expected to exploit the benefit of
the feature.

> This is 
> what SCTP already does.

That's fine.

> I don't see how this is separating the locator 

Reasoning in the draft is related to reverse look up with local
addresses.

The more strong reason is that implementation becomes a lot easier
but is not an architectural point

> many things).

It is architecuturally of course that a change at the IP layer
affects many things.

As for deployment, change is optionaly.

As I wrote several times already in this ML, our code is running
interoperating with leagacy hosts.

> The current architecture doesn't differentiate between 

That is an abstract nonsense against the running code.

> place to solve the multihoming problem.

IP layer, (layer 3), of course, is the place to solve the problem
of IP addresses.

Layers above, including but not limited to 4, are, of course,
affected.

NAT is a example (hopefully to a reverse direction) of how a simple
change at IP layer has tremendous effects on layers above.

A good news with out code is that upper layers are not affected
if a host or its peer chooses to stay to be as reliable as
a singly homed host.

							Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 15 May 2003 14:48:38 +0200

On donderdag, mei 15, 2003, at 14:02 Europe/Amsterdam, Masataka Ohta 

> Well, basically, I say hosts should have multiple addresses. It is,

What I mean is that when an applications wants to connect to an 
application on another host, the first application has to find all the 
addresses for the correspondent host and give them to TCP so that TCP 
can start a session.

I don't think this is the right approach. Applications should only work 
with one thing that identifiers the other end and not worry what 
happens on the network.

(BTW, how does the second host learn the alternative addresses for the 
first host?)

> It is architecuturally of course that a change at the IP layer

It shouldn't.

> As for deployment, change is optionaly.

All of the stuff we're discussing right now needs support from both 
ends in order for multihoming on one end to work. This means change is 
NOT optional, we need to get at least 95% of the internet to adopt this 
or we have failed.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 15 May 2003 22:13:28 +0859 ()

Iljitsch;

> with one thing that identifiers the other end and not worry what 

That's merely a terminology concern.

Our TCP has an API accepting multiple addresses.

We also support API over TCP accepting a DNS name of a peer and
nothing more than that, which may be located at transport or
application layer. An interesting property of the API is universal
that it transparently works with IPv4, leagacy IPv6 and multihomed
IPv6 peers.

Or, there can be an API accepting ID of a peer, though it is not
universal.

Note that, architecturally, there is no real difference between
transport and application layers on the best effort Internet,
though, traditionally, something implemented in BSD kernel has
been called transport.

So, you can call all the APIs above TCP, if you so want.

> (BTW, how does the second host learn the alternative addresses for the 

Through DNS reverse and forward lookup, TCP option or some
transport/application specific way.

> > It is architecuturally of course that a change at the IP layer

Remember that promoters of NAT was saying so.

NAT was advertised to be a small harmless change.

> NOT optional, we need to get at least 95% of the internet to adopt this 

Interesting.

According to your logic, IPv6 have failed as IPv6 needs support from
both ends in order for IPv6 on one end to work. As you know, far
less than 95% of the Internet speak IPv6. So, don't bother to
discuss IPv6 multihoming.

On the other hand, the stuff we have finished is interoperating
with 100% of the leagacy IPv6 hosts.

						Masataka Ohta

---

From: Thierry Ernst <[email-masked]>
Date: Fri, 16 May 2003 11:00:31 +0900

> > NOT optional, we need to get at least 95% of the internet to adopt this 

Definitely, if a solution does not require changes at the end nodes,
this solution should be favored. New protocols shouldn't require change
at all implementations to work. This is a bit too late. If we need to
update exisiting implementations everytime there is a new feature on the
table, IPv6 cannot be deployed.

My point is that modifications at the other end should be done ONLY as
an OPTION to make a feature work BETTER. Same as MIPv6: if you don't
implement the CN operation at the other end node's side, it still works,
but not efficiently. 

My 2 euro cents.
Thierry.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 19 May 2003 14:32:12 +0200 (CEST)

> - IP in transit works with locators, everything above the IP layer with 

Yep. And I think tunneling is one approach to implement this.

There might be an attribute of transparency that can be derived from the above
(not that I know we'd agree on it): 
Assume that layer X in the stack is operating on locators (where there might
be arguments for X=transport and X=application, but that is separate
discussion) then X will send a packet with some source locator and some
destination locator.
The transpareency attribute would be that the X layer on the receiver
receive the same packet (apart from TTL) as the sender sent.

> - what should identifiers look like?

More detailed questions in this area are:
 - are identifiers flat or do they have internal structure?
 - are (the fields of) the identifiers managed for uniqueness and other
   purposes or are they more or less random? (If there is internal structure
   potentially different fields can be different in this respect.)

> go with a certain identifier?

And potentially at different time scales:
 - find a set of potential locators from an identifiers (whether or not
   they are currently usable)
 - find a set of usable locators for an identifier (taking into account
   failures that affect one locator but not others)

And potentially at different granularity:
 - site mapping (from site part of identifier to site part of locator)
 - host mapping (allowing host multihoming and host IP mobility)

Agreed.

If there is a system that maps to identifiers to locators there is
also the issue of authenticating and authorizing entries (new and updates)
to that system.

> come up with something better.

I assume you meant "locator selection" and not "address selection". :-)
 
   Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 19 May 2003 23:40:19 +0200

On maandag, mei 19, 2003, at 14:32 Europe/Amsterdam, Erik Nordmark 

> Yep. And I think tunneling is one approach to implement this.

:-)

I don't care much for tunnels. Now if they would really solve anything 
I guess I could live with another wasted 40 bytes per packet but I 
don't think they do as you can't trust any information in the inner 
header. So either you need crypto or you check the inner header against 
know information. But if you knew in the first place, why add the 
header...?

> receive the same packet (apart from TTL) as the sender sent.

I think this is what happens, and I sure think this should be what 
happens.

>  - are identifiers flat or do they have internal structure?

We know that looking up stuff in a flat namespace isn't pretty. If we 
truly want the identifier to be the identifier, then we need to be able 
to look up stuff such as locators based on the identifier. We can also 
have something at an even higher level that is used as the "real" 
identifier, I think this is what the HIP people do by mapping from the 
FQDN to the crypto ID and the locators but not from the crypto ID 
directly to the locators.

>    potentially different fields can be different in this respect.)

I would like to make as few assumptions about the identifiers as 
possible, so we can use different kinds of identifiers and not just 
IPv6 addresses. FQDNs would make good identifiers. Cryptographic hashes 
are also useful identifiers for some purposes. But that means we have 
to design for the lowest common denominator = no real structure = hard 
to look up.

> also the issue of authenticating and authorizing entries (new and 

And yet it has to be simple enough that people who don't know an X.509 
certificate from a piece of toilet paper can deploy it.

> I assume you meant "locator selection" and not "address selection". :-)

Aarghh, yes...

Iljitsch

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 20 May 2003 16:56:23 +0200 (CEST)

> know information. But if you knew in the first place, why add the 

I'm thinking more at a conceptual level where tunneling implies
that a packet logically injected by the "identifier layer"
on one node with source and destination being identifiers 
and being tunneled (by putting it in an IP packet with 
source and destination being locators) to the "identifier layer"
unmodified.
Thus conceptually it is wrapped in an IP packet and then unwrapped.

This doesn't prevent optimizations like avoiding an extra IP header
when it is known that the receiver can map from the pair of
locators in the packet to the pair of identifiers.
To do this compression would require some packet exchange to establish the
state thus for delay reasons it might in some cases make sense to be able
to start sending "uncompressed" packets in parallel with such state being
established.

And perhaps such state should be optional. It isn't likely to be harmful
when the tunnel endpoint is the host, but there might potentially be
scaling issues when the tunnel endpoint is some form of per-site proxy.

So I don't mind avoiding 40 useless bytes either.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 20 May 2003 17:05:48 +0200 (CEST)

> to look up stuff such as locators based on the identifier. 

Yep. It would be interesting to look at distributed hash tables for this,
even if it is probably unrealistic to do lookups on flat host identifiers.

> We can also 

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.

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.

So these are all important tradeoffs to try to understand better.

> to design for the lowest common denominator = no real structure = hard 

Makes sense. 

If the identifier is split into "site identifier" plus "node within site ID"
then it might be feasable to build a distributed hash table for
the site identifier part. 
Some hard issues there is how to secure the DHT (the updates and the
information retrieved from it) - but that might not be that much different
than securing the source identifier received in a packet; solve one and the
other might fall out.

  Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 May 2003 17:14:57 +0200

On dinsdag, mei 20, 2003, at 16:56 Europe/Amsterdam, Erik Nordmark 

> Thus conceptually it is wrapped in an IP packet and then unwrapped.

Yes, this is a good way of looking at it.

> to start sending "uncompressed" packets in parallel with such state 

I see three ways to do this. See the link to a draft I posted on this 
list last week 
(http://www.muada.com/drafts/draft-van-beijnum-multi6-2pi1a.txt) where 
I tried to make this work with as little state as possible. The 
destination identifier in packets to the server is implied, as the 
server can map the locator address used to the identifier without 
maintaining any per-session state. For the client address we can't do 
this so I decided to encode the alternative prefix into the address in 
addition to the regular prefix.

---

From: marcelo bagnulo <[email-masked]>
Date: 20 May 2003 18:41:29 +0200

Hi Erik,

> 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

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

I guess that there are some clear benefits in all the cases, for
instance: if we create a completely new address space, we can use it
fits better to our needs. The first option can provide us with good
backward compatibility, since old hosts can just use the address bothas
identifier and locator and no mapping (i.e. additional security) is
needed. But i am sure that there is much more here for me to
understand...   

> So these are all important tradeoffs to try to understand better.

Fully agree, 

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 :-)
I would even say that this should become a wg document

regards, marcelo

-- 
marcelo bagnulo <[email-masked]>
uc3m

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 May 2003 21:00:00 +0200

This message was supposed to go to my drafts folder but I must have hit 
send...

On dinsdag, mei 20, 2003, at 17:14 Europe/Amsterdam, Iljitsch van 

> addition to the regular prefix.

Five ways. The above uses two different ones for servers and clients:

1. Encoding the locators in the identifier
2. Looking up the mapping from the identifier to locators somewhere
3. Negotiate the mapping before communication happens (like the ISAKMP 
protocol does) but this requires some bootstrapping mechanism
4. Negotiate the mapping during session start
5. Send the packet and receive the mapping state if there is any

I think the simple DNS approach is a good choice to start with unless 
depending on the DNS isn't acceptable. Option 5 could be a reasonable 
alternative if we decide we have to go with crypto (which I personally 
don't care for).

But it's hard to know at this stage what the best approach is, and 
there probably isn't a single best approach. So what I'd like to see 
happen is that we select the simplest option as a default mechanism 
that everyone must implement, but keep the option open for the user to 
override this default behavior in a way that doesn't make the 
implementation too complex.

This could solve the policy problem in enterprises. People running 
enterprise networks have told us they absolutely positively need 
mechanisms to implement traffic engineering and other policies and not 
depend on what any particular host decides is the best way to route a 
packet. With this hook in place hosts could run a daemon that asks some 
central servers about the mapping state and source/dest locator 
preference whenever a session is initiated to a destination for which 
there is no mapping state yet. (A stateless way to see if a destination 
is multihomed or legacy v4 would be good here.)

This has the additional benefit that the dependence on the DNS isn't so 
bad anymore. Mapping information for known correspondents can be cached 
on local storage and periodically updated rather than resolved whenever 
the information is needed.

>> scaling issues when the tunnel endpoint is some form of per-site 

We can make receiving stateless if we create our own mapping for 
sending and depend on return routability. This wouldn't lead to worse 
security problems than regular IP. So if we can make mapping from the 
identifier to the locator for sending stateless we're in stateless 
business.

---

From: Cedric de Launois <[email-masked]>
Date: 21 May 2003 08:17:24 +0200

> is multihomed or legacy v4 would be good here.)

This is exactly what is done in the new draft
http://www.ietf.org/internet-drafts/draft-de-launois-multi6-naros-00.txt

Maybe you should take a look at it. We would appreciate your comments !

Cédric de Launois

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 21 May 2003 09:26:43 +0200

On woensdag, mei 21, 2003, at 08:17 Europe/Amsterdam, Cedric de Launois  

> Maybe you should take a look at it. We would appreciate your comments !

Yes I read it after Brian mentioned it. My main comment is that it only  
addresses the source address if I read it correctly. Why not ask the  
system for the best destination/source combination? And maybe report  
back if something doesn't work so the next host gets better information?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 21 May 2003 11:24:12 +0200

> back if something doesn't work so the next host gets better information?

If we want to develop a multi-address based solution, these questions
would need to be answered. Plus why not do the same thing using DNS.
Plus security, since as proposed it is wide open to attack. But first,
let's decide if we want a multi-address solution.

    Brian

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 21 May 2003 14:09:03 +0200 (CEST)

> locator address space or should be a separate one?

Too early for me to have any opinion - I think we need to understand both the
weak and strong id/loc separation and see what the tradeoffs are.

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

That is what I've seen others call a weak split.
Similar in nature to mobile IPv6 where in some cases an address is
a locator and in other cases an identifier and you can't tell (based on 
its syntax or based on where it appears in packets) which one it is.

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

I think both of these, including an identifier which doesn't fit in 128 bits,
is what I'd call strong separation.

One of many tradeoffs in this space is that if the identifier is 128 bits
in length there might be transition benefits to being able to tell whether
a 128 bit chunk is an identifier or a locator.
For instance, that would allow applications which do getaddrinfo() followed
by connect()/sendto() to receive locators for old peers (those that don't
have an IP identifier and don't do whatever new protocol we come up with)
and receive identifiers for new peers.
Then the stack under connect()/sendto() can look at some leading bits
of the 128 to tell whether it needs to do an ID->locator mapping, or
just send a packet.
But as I said, I think this is only one of the tradeoffs.

> I would even say that this should become a wg document

There is also the NSRG report to look at. It at least
specifies a granularity for the "stack names" which seems like a useful one
to me.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 21 May 2003 14:26:36 +0200 (CEST)

> implementation too complex.

My gut feel is that it is too early to choose a mechanism. But studying
the different possible mechanisms (such as using DNS) to determine what impact
that has on the architecture is a very good thing.

I suspect there are two different ways to do this using DNS:
1. It is possible to lookup both identifier and locators based on a DNS
   name, but the DNS doesn't have a mapping from identifier to locators.
   1a. Perhaps the DNS could have a reverse mapping from locators to DNS names
       aka ip6.arpa as today.
2. The DNS also has a mapping from identifiers to locators.
   Presumably this means that the identifiers must be delegated on some 
   hiearchical boundaries.

> identifier to the locator for sending stateless we're in stateless 

There is a difference between soft-state and hard-state.
I've been silently assuming that any tunnel endpoint/receiver state would
be soft i.e. have similar behavior as the mobile IPv6 state used
when handling the Home Address Option - if there is no state (due to state
loss) and error saying "please update my state" goes back to the sender.
(The ZOD draft by Glenn Morrow was an example of how to do this with
no packet overhead. Perhaps robustness would be better if there is at
least a "generation" number in the header to be able to detect stale state.)

Such a soft-state approach allows there to be multiple independent tunnel 
endpoints (useful e.g. when the site border runs this during transition)
by dynamically being able to discover the state when packets arrive.

But potentially having such soft-state might use up a lot of memory
on the border - this is something we need to understand more.

  Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 21 May 2003 23:58:29 +0200

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

>> 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.

> The other option is to split the IPv6 address space and reserve a part

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.

> 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.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 May 2003 10:39:59 +0200

> properties, but each may act as an endpoint at some point in time.

This is why the NSRG decided to focus on the "stack" as the entity
to be identified (and located). For an IP address, the stack is
the right level, for reasons that the NSRG draft explains.

My opinion is that IPv6 addresses are fine both as stack identifiers
and stack locators, and that identifiers and locators should *not*
be syntactically distinguished - we will simply know from context 
whether we are using an address as an identifier, a locator, or both.

Anything else takes us off into computer science discussions, and I don't
think that is a good use of our time. (In fact, that is why the NSRG
took so long to come up with a draft, which isn't even a consensus.)

   Brian

---

From: marcelo bagnulo <[email-masked]>
Date: 22 May 2003 10:43:52 +0200

Hi Iljitsch,

> the locator and identifier functions.

Agree, but i would say that any multi-address solution that preserves
established communications does implements some sort of loc/id split.
more below...

>  Address agile transports simply 
> single addresses do in TCP and UDP.

I am not so sure about this. I guess that any proposal of address agile
transport layer must present only ONE single address to the application
layer, which plays the role of identifier, while all the others address
plus this one are the locators.
The difference here is that the distinction is made in the transport
layer and not in the IP layer, but from the application POV there is
still only one identifier and from the routing POV there are multiple
locators.
There is still the option of letting the application to manage multiple
addresses. In this case, you can say that the identifier is the set of
locators, but i digress...

>  MIP uses the loc+id for the home 

I do not understand what you mean here...
HoA is an identifier and one of the possible locators and CoAs are
alternative locators, do you have an alternative interpretation?

> supported widely yet? I seem to remember this was "mandatory" 

I think route optimization support on CN is a SHOULD.

> but as 

I have to disagree here... HIP splits Loc and id and it can be used to
solve the mh problem, so i see no reason to not consider it as such

I think that many folks agree that the problem is that the a loc and an
id  are univocaly mapped since there is a single name (IP address) that
performs both functions. So, the solution would be to extend the mapping
to support the relation between one identifier and multiple locators.

Perhaps there is some agreement in this.

How to actually implement it? Well, all the above proposals do this in
very different ways, so we still have to discuss this.

But As Tony already proposed, we should first reach consensus on the
Loc/id split approach is the way to go. Well, at least the long term
approach. 

> properties, but each may act as an endpoint at some point in time.

I think that the first decision is to decide where to implement the
loc/id split. IMHO it should be done between the IP layer and the
transport layer (or by the upper part of the IP layer, if you wish)
Then, i guess that multiple identifier can be supported so that you can
associate with any element residing above the IP layer that you consider
useful.

Regards, marcelo

---

From: Tim Chown <[email-masked]>
Date: Thu, 22 May 2003 09:58:47 +0100

>    Presumably this means that the identifiers must be delegated on some 

Well, we do have ENUM as an example of a DNS system which maps from a type
of identifier (E.164 number) to a locator (URI for service+FQDN) via the
returned NAPTR record in the .e164.arpa space.

Tim