Subject: identity persistence and comparison issues

From: Joe Touch <[email-masked]>
Date: Mon, 14 Jun 2004 12:12:51 -0700

Hi, all,

Here are the issues I sent separately to Elliot Lear to add to his 'q&a' 
draft, which might overlap some of the content of Geoff Huston's...

----------------

Some additional questions came to mind; use at your own risk...

1. you ask if a solution can be aggregated

     this presumes that aggregation is beneficial,
     i.e., it would be useful to add
     "is aggregation useful or necessary to the solution?"

2. you asked about load on nameserver. based on some solutions I've 
seen, it would be useful to ask:

     does the solution create an alterate DNS-like service?
     should this be separate from or part of the DNS?

3. does the endpoint ID change on the fly or is it static/cacheable?

     specific variants of this issue:

     a) are two IDs comparable within the same app over time?
         i.e., can an ID change? if so, can the old ID be used?

     b) can two IDs on different apps on the same node be compared?

     c) can two IDs on different nodes be compared?

this specifically affects debugging, logging, and caching.

Joe

---

From: Geoff Huston <[email-masked]>
Date: Tue, 15 Jun 2004 06:29:54 +1000

Many thanks Joe - I'd be willing to use these points.

   Geoff

At 05:12 AM 15/06/2004, Joe Touch wrote:
>2. you asked about load on nameserver. based on some solutions I've seen, 
>it would be useful to ask:
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Jun 2004 09:18:40 -0700

>     c) can two IDs on different nodes be compared?

During the meeting there was some talk about per-session identifiers. 
Wouldn't such identifiers be pretty much useless?

What I want from an identifier is be able to set up sessions towwards 
it, the same way I can now with a FQDN or IP address. If this isn't 
possible, what use are these identifiers? In this situation an 
identifierless solution would be better. And if there are ephemeral 
values that are used internally somewhere, we should probably avoid 
calling them "identifiers".

In the good old days it would have been possible to presume that if two 
FQDN or IP address values are identical, they point to the same host. 
However, in these days of load balancers this is no longer true, 
although it's usually safe to make this assumption in applications 
because the different hosts would be providing the same service.

In the design team # 1 we had some discussions on the FQDN <-> ID <-> 
locator relationship and I think we agreed that the ID should be tied 
to a single host, even if the FQDN is shared between more than one 
host.

Obviously it must be possible to change identifiers. This means it must 
be possible to have more than one at the same time or operators will 
revolt. Another reason to have more than one ID at one point in time is 
for privacy reasons, this would be similar to RFC 3041.

---

From: Joe Touch <[email-masked]>
Date: Wed, 16 Jun 2004 10:39:33 -0700

> Wouldn't such identifiers be pretty much useless?

They're used in HIP, e.g.

> calling them "identifiers".

The name of the endpoint (A) that you talk to isn't the same as the name 
used for forwarding (B), which may not be the same as any of the 
multiple endpoint addresses (C1...CN).

The one I'm referring to is B. A might be a DNS name or current 'well 
known' IP address used to bootstrap the communication.

> FQDN or IP address values are identical, they point to the same host.

A FQDN has always been mappable to multiple IP addresses. If two IP 
addresses are identical, it is still the case that they either point to 
the same host or something that emulates one host.

> because the different hosts would be providing the same service.

When load balancers break the 'same host or equivalent' they can 'break 
the Internet' (e.g., arbitrary protocols can break).

> locator relationship and I think we agreed that the ID should be tied to 
> a single host, even if the FQDN is shared between more than one host.

A must be tied to a single host or something that emulates such, for the 
reasons above.

> for privacy reasons, this would be similar to RFC 3041.

Changing A is like renumbering now; a slow, out-of-band operation that 
requires resynchronization (e.g., of the DNS). Changing B is more of an 
opportunity than a liability...

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 16 Jun 2004 23:53:35 +0200

Joe Touch wrote:
>> In the good old days it would have been possible to presume that if 
>> two FQDN or IP address values are identical, they point to the same host.
> 
> 
>> to a single host, even if the FQDN is shared between more than one host.
> 
> 
>> Obviously it must be possible to change identifiers. This means it 
>> must be possible to have more than one at the same time or operators 
>> will revolt. Another reason to have more than one ID at one point in 
>> time is for privacy reasons, this would be similar to RFC 3041.
> 
> 

I think this is a very hard conversation to have in the abstract.
I think it will be much easier to analyze these questions in terms
of a specific proposal. So maybe we should note them as open, until
our ongoing reduction of the solution set from many to few has
been achieved.

   Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 17 Jun 2004 00:31:25 +0200

Hi Iljitsch,

> possible, what use are these identifiers?

As i see it, there are two ends involved in a communication, the 
initiator of the communication and the responder.

The responder of course has to have a stable id through which the 
initiator has to be capable to establish a communication with.

I mean, the responder needs a stable id that it is known by the 
initiator in order to make initial contact.

Now, the initiator may not need to have such a stable identifier, since 
the initiator does not receive communications. what the initiator needs 
is an identifier that is stable during the communication lifetime so, 
if the locator change, the identifier is maintained so it is the 
communication.

So there are different requirements imposed to the intitator's 
identifier and the responder's identifier

The responder's identifier has to be stable and known a priori so it 
can be used to make initial contact
The intitiator's identifier has to be preserved during the 
communication lifetime and does not need to be known a priori (in the 
general case)

Clearly and option would be to provide stable identifiers both to 
initiators and responders, but the issue here is that the security 
required  by a stable identifier is likely to be more expensive than 
the security required by a ephemeral identifier. SO why would you 
provide additional (costly) features when they are not needed?

>  In this situation an identifierless solution would be better. And if 
> there are ephemeral values that are used internally somewhere, we 
> should probably avoid calling them "identifiers".

Well, i usually make the difference between ephemeral ids vs. stable 
ids.
ephemeral ids are valid during a communication lifetime
stable ids are more long lived and can be used for initial contact

regards, marcelo

> two FQDN or IP address values are identical, they point to the same 
> host. However, in these days of load balancers this is no longer true,

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 23 Jun 2004 16:28:34 -0700 (PDT)

> if the locator change, the identifier is maintained so it is the 

I agree in principle, but I'm concerned this is a theoretical
observation because I don't think we can build systems that
know what the lifetime of the communication is.

It is true that in many cases "communication lifetime" = "TCP connection
lifetime", but if we build solutions assuming this then they will
fail for the cases when the equality doesn't hold; whether the
communication consists of UDP traffic, referrals, callbacks, or just
multiple TCP connections between the same nodes.

One could argue that the application should inform the "stack" about
the lifetime of the communication, perhaps by defining some new "open"
and "close" APIs, i.e. getting close to defining a session layer.
But my gut feel is that this requires more changes to the applications
than is warranted.

  Erik

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 24 Jun 2004 11:29:15 +0200

> multiple TCP connections between the same nodes.

I agree

However, i wonder if this issue is not more general and it is not 
limited to only ephemeral ids proposals

(not considering the refferral and call back cases here)

I mean, in any proposal that manages bindings between multiple locators 
that can be used to reach a single endpoint, you need some state in the 
endpoints about the binding. This state has to be preserved as long as 
the communication exists, and some garbage collection mechanism is 
needed to delete this state after it is used.
As you mention, the wedge layer does not have knowledge about the apps 
still need the binding state, so how do you know when to delete it?

For example, how does this work in the hip case?
a node A starts a communication with node B, so the node A obtains 
through the DNS the HITB and the locators of node B
Node A then generates a state that maps HITB with the set of locators 
associated with the node B
Now how long this state is preserved in node A? and how does the node A 
knows when to delete it?
I mean, perhaps there is an app that has been quiet for a long time and 
wants to continue the communication afterwards, what happens if the 
binding information between the HITB and the locators have been 
deleted? in HIP this is even more difficult because there is no way to 
obtain the set of locators from a HIT...

I guess that the solution would be to use very long garbage collection 
times, but as you have mentioned sometime before, this approach may 
introduce some additional danger and it clearly does not guarantee that 
all apps will be satisfied

am i missing something? Any ideas?

regards, marcelo

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 24 Jun 2004 12:44:57 +0200

> But my gut feel is that this requires more changes to the applications

Hm, I think you're overlooking the fact that in any case where 
referrals happen, the host that's being referred to must accept 
incoming connections. An application waiting for incoming connections 
is something that's pretty easy to detect for a host stack...

In other words, the bind(2) call can trigger the creation of a 
longer-lived identifier. Still, I'm not sure how applications determine 
which address to use in referrals, it may be necessary to make this an 
explicit API call = application changes = a bad thing.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jun 2004 23:15:29 +0900

marcelo bagnulo braun;

> still need the binding state, so how do you know when to delete it?

Just say NAT.

> For example,

Of course, there are many cases where NAT-like approaches
just does not work. A notable example is (v4)FTP.

> how does this work in the hip case?

It has nothing to do with hip and it does not work.

> Now how long this state is preserved in node A? and how does the node A 

A NAT operator can give you the answer that it is 5 minutes.

> wants to continue the communication afterwards,

and the reality of the Internet is ignored by people promoting
NAT.

> am i missing something?

No, not at all.

> Any ideas?

We need yet another WG or a standardization body.

							Masataka Ohta

PS

If you still believe in IETF, try to argue against me in v6 ML on
my reasoning about why ND over WLAN is useless.

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 24 Jun 2004 23:20:28 +0900

Iljitsch van Beijnum wrote:

> Hm, I think you're overlooking the fact that in any case where referrals

In short, end systems can not be transparent to address (locator)
rewritings.

I guess that most people in the last interim meeting are so stupid
thay they couldn't have any chance to notice such a basic fact.

However, I'm still waiting fof the meeting minutes, even draft
ones, to confirm it was really so.

							Masataka Ohta

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Jun 2004 15:42:15 +0200

Iljitsch van Beijnum wrote:
> happen, the host that's being referred to must accept incoming 
> connections. An application waiting for incoming connections is 
> something that's pretty easy to detect for a host stack...
> 

That's an interesting point. In a 2-way conversation, a 'close' on a socket
is a strong signal that the stack can forget any state (unless there is
some optimization possible by caching the state). In a referral conversation
that is no longer true - but presumably the referred ID cannot be ephemeral
anyway. Or to say it another way, referrals will only be possible with
long-life IDs. To avoid *any* apps changes, those long-life IDs are going
to have to look exactly like IP addresses, IMHO.

    Brian (not in the chair at this moment)

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Jun 2004 08:32:42 -0700

> Iljitsch van Beijnum wrote:
...
>> longer-lived identifier. Still, I'm not sure how applications 
>> determine which address to use in referrals, it may be necessary to 
>> make this an explicit API call = application changes = a bad thing.
> 
> 
> some optimization possible by caching the state)....

'close' is an app-side input to the stack; there are other 
considerations about when to drop state.

E.g., TCP has to keep TIME_WAIT to avoid reusing ports/seq numbers. At 
which point addresses from elsewhere cannot be moved 'here' until these 
timers expire.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 Jun 2004 22:26:19 +0200

> which point addresses from elsewhere cannot be moved 'here' until these 

Correct, of course. As usual I abbreviated... but in the absence of the clean up
by a transport protocol, i.e. for UDP, the 'close' is all you have.

     Brian

---

From: Joe Touch <[email-masked]>
Date: Thu, 24 Jun 2004 17:39:24 -0700

> know what the lifetime of the communication is.

We do know. The lifetime is unlimited. A TCP connection can stay up as 
long as the two endpoints stay up.

The identifier needs to be stable at the endpoints as long as the 
endpoints care - which is why I like how HIP negotiates these labels, 
and maintains the mapping at the endpoints. The endpoints are the only 
place that can or should know about whether they change.

Joe

---

From: marcelo bagnulo braun <[email-masked]>
Date: Fri, 25 Jun 2004 10:39:43 +0200

Hi Joe,

El 25/06/2004, a las 2:39, Joe Touch escribió:
> and maintains the mapping at the endpoints.

Yes, but for how long does the hip endpoint maintains the mapping 
between the HIT and the locators of the other endpoints?

I mean, there must be a garbage collection mechanism, if not the hip 
endpoint will have to store infromation about all the endpoints that it 
has communicated with in the past

regards, marcelo

>  The endpoints are the only place that can or should know about 
> whether they change.
>
> Joe
>

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 25 Jun 2004 18:23:01 +0200

>>  The endpoints are the only place that can or should know about 

This is a purist view of the Internet we used to have when RFC 1958
was written... the current reality (RFC 2775) is that all these
problems call for soft state solutions, that can be garbage collected
as Marcelo says, and recreated if they are prematurely lost.

(The tragedy of NATs is that they can't do the second bit reliably,
and multi6 needs to avoid that problem.)

     Brian

---

From: Joe Touch <[email-masked]>
Date: Fri, 25 Jun 2004 18:58:44 -0700

...
> as Marcelo says, and recreated if they are prematurely lost.

Soft state elsewhere is an optimization that relies on hard state at the 
endpoints for its recovery and recreation anyway. I.e., I don't see 
yours and Marcelo's views as inconsistent.

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 26 Jun 2004 12:24:48 +0200

El 26/06/2004, a las 3:58, Joe Touch escribió:

> Soft state elsewhere is an optimization that relies on hard state at 
> the endpoints for its recovery and recreation anyway. I.e., I don't 
> see yours and Marcelo's views as inconsistent.
>

One problem is that if the endpoints are incapable of obtaining the 
locators associated with a given identifier (as in HIP), it is 
impossible for the endpoints to recover the lost state, so perhaps 
having a mechanism for mapping id to locators is a must?

regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 27 Jun 2004 16:30:43 -0700 (PDT)

[I took the liberty to change the subject since this isn't about the
persistence of the IDs; it is whether the mappings from IDs->foo
can be viewed as caches or whether they are hard endpoint state]

> still need the binding state, so how do you know when to delete it?

One possibility is that the information is a cache, similar in nature
to the ARP cache,
where information can be discarded because it can be rediscovered
based on what exists elsewhere in the node. That would make the
caching strategy a performance tradeoff - how much state to retain
compared to how much does it cost to recreate the state.

Given that the ULP might only have a 128 bit handle, it is hard for
me to see how one can recreate the state in the presence of 
unreachability for some locators, without some 3rd party infrastructure.

> having a mechanism for mapping id to locators is a must?

I think I agree, but I would rephrase it as
For existing applictions, whatever 128-bit thing they pass to sendto() and
connect(), should have the property that the multi6 layer/sublayer
can create or recreate whatever state it needs based on that bit string.

I wonder, assuming we are successful, there will be applications that are
aware of the id/locator split thus will know to deal with both quantities
instead of just a 128-bit string, which is why I rephrased it as above.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 27 Jun 2004 16:38:05 -0700 (PDT)

> is something that's pretty easy to detect for a host stack...

I think you're overlooking that UDP doesn't have the concept of incoming
connections :-)

Seriously, I don't see how we can make any detection/heuristic that
can determine whether the identifier needs to be able to survive
across e.g. multiple socket calls at the API.
 
> explicit API call = application changes = a bad thing.

But even this is hard for TCP unless I misunderstand your idea.

Suppose an application which doesn
1. Client connects to the server.
2. Client asks server do perform X.
3. The server might be able to perform X immediately in which case it returns
   the results on the same connection,
   or the server says "I'll call you back later".
   In the second case we get
	4. Client creates listening socket. Tells the port number to the server.
	5. Existing socket is closed
	6. Later server calls back the client

In this case the server takes the "identity" (getpeername()) from
the connection created in 1 as the place to call back.
Thus allocating a longer-lived identifier in 4 wouldn't help,
unless you want to modify the application.

   Erik

---

From: Jukka Ylitalo <[email-masked]>
Date: Mon, 28 Jun 2004 10:28:26 +0300

> between the HIT and the locators of the other endpoints?

HIP:

For my best understanding, the HIP I-D does not explicitly specify  the 
context  lifetime.
Although, the IPSec Security Association lifetime plays an important 
role in HIP.
In our HIP implementation the IPSec SA is stricly bound to the HIP 
context. Once the
SA is deleted, so will be the corresponding HIP context.

When the SA lifetime expires, the IPSec typically triggers an UPDATE
message updating the SA.  In our implementation, if the UPDATE exchange 
fails,
the host destroys the corresponding HIP context. In addition, in BSD, if 
there are no traffic
within  t seconds, the SA expiration does not trigger a new UPDATE 
message, but just
deletes the SA, and as a consequence also the HIP  context.

Multi6:

It  seems to me  that Multi6 wedge3.5 protocols could benefit from IPSec SA
kind of semantics. That is, each host specifies its own policy for 
context lifetime.
(It is good to notice that this proposal is not related to actual IPSec 
in anyway).
Once the context lifetime expires, it triggers a new context lifetime 
update exhange.
If the Multi6 implementation does not find out any traffic during a 
while, it
just deletes the context (like with IPSec in BSD). However, the next packet
sent via the open socket would trigger a new full context establishment 
exchange.

Any opinions?

> endpoint will have to store infromation about all the endpoints that 
> it has communicated with in the past
>
You are right that there exists a problem. A host that destroys a HIP 
context may still
have an open socket bound to HITs. Now, if an application sends a packet 
using the
HITs, the packet triggers new HIP base exchange. However, the host does 
not have
anymore information about the destination locators where to send the HIP 
base
exchange packets. Thus, we end up with problems.

I would like to see a Multi6 variant of HIP that uses routable 
IP-addresses as
application identifers, instead of HITs.
(I will return to this topic in my reply to Erik, in the next mail.)

br, Jukka

-- 
Jukka Ylitalo                      Tel: +358 9 299 2622
NomadicLab, Ericsson Research      Fax: +358 9 299 3535
Oy L M Ericsson Ab                 Mobile: +358 400 615 821
FIN-02420 Jorvas, Finland          E-mail: [email-masked]

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Jun 2004 10:33:45 +0200

> I think you're overlooking that UDP doesn't have the concept of 

Sure it has, the connections just don't last longer than one packet.  
(-:

I haven't written anything that handles incoming UDP packets, so I 
don't know for sure, but unless I'm very much mistaken applications 
need to do a bind() call before they can receive UDP packets too.

> across e.g. multiple socket calls at the API.

Yes, this can be a problem that may require application changes to 
solve.

> unless you want to modify the application.

I don't think I see your problem. If the system uses a long-lived 
identifier at step 4, and the application obtains this identifier from 
the system, we're in business, I think. The problems start when the app 
tries to discover the identifier before step 4 and it obtains a 
short-lived one.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Jun 2004 12:16:16 +0200

> Ah - so "connection" survivability for UDP-based apps then becomes 
> quite easy
> since the problem doesn't exist :-)

Well, yes. But UDP really needs the ability to set up new connections 
very badly...  8-)

> I don't know what the API standards say, but in many implementations
> the app can just do a sendto() which will make UDP pick a port number
> for the duration of the lifetime of the socket. Thus the application
> will be able to receive packets sent in to that port number.

Ok, I don't have enough information to determine whether this is a show 
stopper or not.

> The problem is that the unmodified server extracts the identifier (aka 
> IP
> address) in step2 thus you'd need to make the client pick a long-lived
> identifier in step1, or make step4 pass the identifier+port to the 
> server.
> In either case this implies modifications to the application.

What if we just always show the application a long-lived identifier, 
even though when it sets up a session we use ephemeral identifiers? If 
the application then doesn't do referrals there is no issue as the 
long-lived identifier doesn't leave the host. If it does "contact me at 
xxx" type referrals there is also no problem as xxx is the long-lived 
identifier so the reference remains valid over (a reasonable amount of) 
time. Only in the case of "you'll hear from me and I'm xxx" type 
referrals wouldn't work, but those won't work reliably in the presence 
of multiple addresses anyway.

Obviously there can be a new API call that allows applications to find 
the actual identifier used.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jun 2004 02:23:44 -0700 (PDT)

> sent via the open socket would trigger a new full context establishment 

A potential problem (don't know how serious it is for multi6) with
having each end indepdently decide when to discard its state is that you
can end up with one end retaining state and the other not.
Normally this is not an issue, but when the end which retained the state 
(call it A) again wants to communicat with the other (call it B)
then B will need to send back some error saying "I've lost or intentionally
discarded my state". With such a mechanism one might need to be careful
about attackers, which were not on the path when communication started
but has since arrived on the path, being able to fake the "lost state" message
thereby being able to insert itself as a MiTM.

The problem is we don't have any existing (IPv4) experience to compare with
there to determine whether this is something we need to be concerned about,
because so far nodes have not been moving around that much in the topology.
I don't know if there are examples of attacks at WiFi hotspots
that can help us understand whether we need to be concerned about this.

If we do, one potential way to address it would be for the endpoints
to coordinate discarding their state e.g by using timers known to the peer
and/or explicit messages.

  Erik

can end up with the case when either end

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jun 2004 02:32:34 -0700 (PDT)

> Sure it has, the connections just don't last longer than one packet.  

Ah - so "connection" survivability for UDP-based apps then becomes quite easy
since the problem doesn't exist :-)

> tries to discover the identifier before step 4 and it obtains a 

The problem is that the unmodified server extracts the identifier (aka IP
address) in step2 thus you'd need to make the client pick a long-lived
identifier in step1, or make step4 pass the identifier+port to the server.
In either case this implies modifications to the application.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jun 2004 05:45:16 -0700 (PDT)

> even though when it sets up a session we use ephemeral identifiers? 

That's part of what Jukka and I were pondering a bit.
I think it is very interesting; just need to make sure that
the additional local mapping on the host from the long-lived to
the ephemeral doesn't introduce attacks that we don't know how to
handle.

> If 

And if the long-lived ID is one of the locators we can provide compatbility
for unmodified applications which do referrals and callbacks.

  Erik

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 28 Jun 2004 15:40:51 +0200

> the ephemeral doesn't introduce attacks that we don't know how to

Terminology questions: the application would only use the stable (long 
lived) id, right?
The ephemeral id is internal to the multi6 layer, and it is not handled 
by the ULP, right?
would then this ephemeral id would be an id, or is this simply a key or 
a token, just as in IPSec or pbk?

regards, marcelo

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 28 Jun 2004 07:25:05 -0700 (PDT)

> Terminology questions: the application would only use the stable (long 

Yes and no.

I see two reasons to be able to isolate the application from the ID
used by the multihoming mechanism:
1. Allow ephemeral IDs by the multihoming mechanism.
2. Allow, perhaps stable, IDs in the multihoming mechanism that can't be
   used for referrals, or that are not 128-bits long (such as the FQDN as
   part of NOID)

For both these reasons you don't want unmodified (non-multi6-aware)
applications to see the internal ID.
But in the case of #2 (and I haven't thought about #1) it might make
sense to allow modified (multi6-aware) applications from
finding the internal IDs as well as the current set of locators which
are used with that ID.

> a token, just as in IPSec or pbk?

In some cases it might be just a context id/context tag (I try to avoid
to use the term "session" since it implies L5 to me),
but in other cases like NOID and HIP it might imply something longer
like a FQDN or a public key.

   Erik

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 28 Jun 2004 17:51:50 +0200

> for unmodified applications which do referrals and callbacks.

We should really talk to some apps people to figure out how important 
this is. It's entirely trivial to shoot yourself in the foot today with 
NAT or multiple addresses anyway, and then there is dual stack. How are 
referrals going to work when a future participant in the communication 
may be limited to one IP version, which happens to be the other one 
than the one used by current participants?

It may very well be that apps and protocols need to be changed anyway 
in order to work with IPv6, or IPv4+IPv6.

---

From: Joe Touch <[email-masked]>
Date: Mon, 28 Jun 2004 10:29:17 -0700

> having a mechanism for mapping id to locators is a must?

That is one of my concerns...

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Jun 2004 13:30:31 +0200

Iljitsch van Beijnum wrote:
> may be limited to one IP version, which happens to be the other one than 
> the one used by current participants?
> 
> It may very well be that apps and protocols need to be changed anyway in 
> order to work with IPv6, or IPv4+IPv6.

The point is that today, the underlying assumption of most applications
is that the IP address they get back from an A or AAAA query, or any
other source including manual config, is a permanent identifier with
the nice property that the routing system can use it as a locator.

NAT breaks this assumption of course. But we are trying to repair the
damage done by NAT. So I suggest that a multi6 goal should be that the
thing an application gets back from an AAAA query, or any other source
including manual config, must be a permanent identifier with the
nice property that something below the socket API can transform it
into a locator.

Which leads me to wonder whether session survival for sessions using
temporary things such as RFC 3041 addresses is a reasonable goal for
multi6.

    Brian

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jun 2004 05:08:30 -0700 (PDT)

> in order to work with IPv6, or IPv4+IPv6.

My experience, and I think Kurt said something similar, is that it
is hard to engage application folks without something concrete like
a proposal that they look at. This makes it tricky to get feedback before
we have nailed down enough of the approach to be able write down how it
will affect applications, unless we do the work to present the apps folks
with a menu having different choices.

  Erik

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 29 Jun 2004 06:00:27 -0700 (PDT)

> nice property that something below the socket API can transform it

Agreed, except that temporary/permanent is not binary but a continutiy
of different lifetimes.

> temporary things such as RFC 3041 addresses is a reasonable goal for

rfc 3041 temporary addresses have a default valid lifetime of 1 week.
So why wouldn't be reasonable for connections using such addresses
to be able to survive failures that last for a few minutes or hours?

Having said that, solutions which rely on the DNS for verifications
might be tricky unless the RFC 3041 addresses have forward and reverse DNS
entires (with a temporary FQDN to prevent correlation to the other
IP addresses of the host).

But this difficulty should distract from the desirability of making
things work for RFC 3041 addresses IMHO.

   Erik

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 29 Jun 2004 15:07:05 +0200

> with a menu having different choices.

What they see is an API and its explicit and implied semantics. So not only
do we need to resolve the endless debate about the nature of an id, we also
have to figure out how that will be represented in socket semantics.

 From painful experience, it is not easy to persuade middleware designers
to change anything in the way they use sockets.

    Brian

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 29 Jun 2004 16:05:05 +0200

> >>in order to work with IPv6, or IPv4+IPv6.

getaddrinfo() doesn't require much changes on the network code front.
The user interface though tends to break when it forces a certain format
or restricts input. Developers should stick to accepting at least
hostname or actually any characters in [a-zA-Z\:\-\.], the problem here
is though that for IPv6 suddenly if you want to parse a URI and allow
IPv6 addresses to be specified you need to know about the [] semantics.

The trick IMHO is to never allow IP addresses to be used basically.
But there are many arguments against this eg 'how do I setup my
home-gateway which comes pre-installed as 2001:db8::1, that thing is
going to run DNS and I need to connect using HTTP'. Simple solution:
/etc/hosts but still ;)

> to change anything in the way they use sockets.

Even pursuading folks to start using getaddrinfo() doesn't work that
easily and most of them have a point.

A network application developer actually only wants this:
8<---------
char uri[] = "tcp://hostname:service";
sock = uriconnect(uri);
-------->8

A function similar like that should be abstracted by the networking
API's. getaddrinfo() requires a loop, weird cases etc, which you have to
duplicate in every application. The above would simply work(tm) and
doesn't require the application developer to worry about anything
networkish. The socket now presented by the API is for the application
the identifier and the only thing the API (or most probably the kernel)
would now have to do is make bloody sure that it keeps working, even if
it has to change underlying addresses etc. uriconnect() can abstract all
of that, the socket(), getaddrinfo() loop and the connect() call.

The identifier 'tcp://hostname:service' in this case will stay the same
and can be passed across most if not any boundaries (of course not
taking the assumption that somebody uses dns paths...) to other
applications in other networks etc.

Another option to look at is adding a function getidentifier(sock)*,
which returns a globally unique (we did have an globally unique IP
address hmmm... :) identifier, which then can be passed around.

The later is IMHO not a nice option as that would require changing many
applications (for IPv6 support they will have to change too so it is
kind of a moot argument), though it could be used. The getidentifier()
could btw return 'tcp://fdqn:service' making sure the above problem with
dns-path searches disappears.

I could then still do: sock = uriconnect("tcp://purgatory:http"); to
contact the http service on purgatory.unfix.org, as my search path
includes 'unfix.org', while when I want to pass it, I would do:
fprintf(sock, "I am looking at: %s", getidentifier(sock));
or a similar construction, which would throw:
"I am looking at: tcp://purgatory.unfix.org:http"

Server side can do the same:
 sock = uriaccept("tcp://:http");
 printf("The one who connected is %s\n", getidentity(sock)); 

Thus passing URL-like identities in applications seem to be the trick
IMHO, an application developer should not have to care about anything
else. Of course the other side app should then also know about HTTP etc

Long story short:
 Maybe it would be an idea to create a draft which includes the
 examples I mentioned above and start hinting developers to start
 using those functions?

Greets,
 Jeroen

* = of course:
char *getidentifier(int socket, char *buffer, unsigned int buflen);
to make sure that it also works with multithreaded apps...

PS: Including the protocol (tcp/udp) won't work easily for server side
stuff... especially with udp not really having an accept.

PS2: I usually tend to abstract the socket/getaddrinfo/connect into
a function like the one mentioned above and that works perfectly well.

PS3: 'High-performance' networking API's like those on Windows have a
completely different strategy of doing things thus fitting those into
the above model will be problematic too...

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 29 Jun 2004 16:35:41 +0200

El 29/06/2004, a las 13:30, Brian E Carpenter escribió:

>> this is. It's entirely trivial to shoot yourself in the foot today 
>> with NAT or multiple addresses anyway, and then there is dual stack. 
>> How are referrals going to work when a future participant in the 
>> communication may be limited to one IP version, which happens to be 
>> the other one than the one used by current participants?
> including manual config,

including a referral?

>  must be a permanent identifier with the

i agree with this

regards, marcelo

---

From: Jeff Williams <[email-masked]>
Date: Tue, 29 Jun 2004 20:01:51 -0700

Brian and all,

Brian E Carpenter wrote:

> damage done by NAT.

  NAT has nor is doing any damage.  Rather NAT provides for greater
flexibility as well as a sort of built in security/privacy feature.  Of
course,
some technical ideologues differ with this view of NAT.

> So I suggest that a multi6 goal should be that the

 Wonderment is a bugger isn't it?

>     Brian

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail [email-masked]
 Registered Email addr with the USPS
Contact Number: 214-244-4827

---

From: Geoff Huston <[email-masked]>
Date: Wed, 30 Jun 2004 12:22:29 +1000

draft-huston-multi6-architectures-01.txt has been published by the drafts editor. This version integrates comments made by working group members on the -00 version and also includes material proposed in the interim multi6 working group meeting earlier this month.

I would like to propose to the chairs that the working group consider:

- that this document be adopted as a working group document, and

- that the appendix of this document be split off from the main text of the document and separately developed as a working group document.

thanks.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jun 2004 14:25:32 +0200

Geoff, thanks.

Because of the way our charter is currently written, we have two separate
questions to the WG. Here is the first one:

Do people agree to adopt this draft as a WG draft (which means
that the next update will be draft-ietf-multi6-architectures-00.txt)?

That doesn't mean you have to agree that it's perfect, just that it
is a good basis for a WG deliverable.

Please answer this question without worrying whether the Appendix
is split off, and please respond by July 9th.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter
Distinguished Engineer, Internet Standards & Technology, IBM

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 Jun 2004 14:28:11 +0200

And here is the second question:

Do people think the Appendix to this draft, which is a preliminary
analysis of various proposed approaches, should become a separate
document? If the answer is yes, we have to discuss with our Area
Director how this would fit into the WG charter.

    Brian

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 30 Jun 2004 16:41:20 +0200

Hi Geoff,

El 30/06/2004, a las 4:22, Geoff Huston escribió:

> draft-huston-multi6-architectures-01.txt has been published by the 
> drafts editor. This version integrates comments made by working group 
> members on the -00 version and also includes material proposed in the 
> interim multi6 working group meeting earlier this month.
>
> - that the appendix of this document be split off from the main text 
> of the document and separately developed as a working group document.
>
>
> thanks.
>

Some comments about the draft:

- About MIPv6: imho we have an important thing to learn from mipv6 (in 
its current form) which is that return routability type of mechanisms 
are not suitable to address the multihoming problem. this is a 
fundamental problem, because in mipv6 the identifier ownership is 
proven by periodical reachability tests. Considering that multihoming 
deals with outages, the reachability tests will fail when there is a 
failure. the periodicity of the tests is required to avoid attacks 
shifted in time

- About traffic engineering: imho is within the scope of a multihoming 
solution, since i think TE are included among the goals stated in RFC 
3582. In particular

3.1.2.  Load Sharing

    By multihoming, a site should be able to distribute both inbound and
    outbound traffic between multiple transit providers.  This goal is
    for concurrent use of the multiple transit providers, not just the
    usage of one provider over one interval of time and another provider
    over a different interval.

and also:

3.1.4.  Policy

    A customer may choose to multihome for a variety of policy reasons
    beyond technical scope (e.g., cost, acceptable use conditions, etc.)
    For example, customer C homed to ISP A may wish to shift traffic of a
    certain class or application, NNTP, for example, to ISP B as matter
    of policy.  A new IPv6 multihoming proposal should provide support
    for site-multihoming for external policy reasons.

So, i guess that a multihoming solution should try to provide these 
goals, and imho an analysis of the solution space should consider these 
items.

- About section 2.

imho this section has improved in this version and now provides a more 
general approach, since it explicitly addresses both the site 
visibility, the session resilience cases and also TE stuff. However, 
perhaps it would be interesting to also include the case when the 
internal hosts attempt to initiate a communication after a failure?
I mean, when a failure occurs, there are three situations to be 
considered, imho. first, session resilience, second that an external 
host is capable of establishing new communications with multihomed 
hosts, and third that a multihomed host is capable of establishing new 
communications with external hosts after the outage, i think that the 
last case is missing.

- about section 4.2

where it states that:

   "The implication here is that if
    the local host wishes to maintain a session across such events it
    needs to communicate to remote host R that it is possible to switch
    to using a destination address for the multi-homed host that is based
    on ISP B' address prefix."

i think that the implication here applies both to established 
communications and to new ones
Additionally i am not sure that it is required that the local host 
informs R about the available locators. As Brian said once (if i 
remeber correctly), the local host is the last one to find out that one 
of its own locators in no longer working. IMHO what is needed is that R 
  discovers which is the new locator to use
So, i would rephrase it into something like:

    The implication here is that in order to enable the communication
    between R and the local host across such events, the remote host R 
has to discover that
    it has to use a destination address for the multi-homed host that is 
based
    on ISP B' address prefix.

(but if you understand my concerns, you can rephrase it much better 
than this, i guess :-)

- about section 4.4

at the end of the first paragraph it is stated than:

    "This modification could be undertaken
    within the transport protocol stack element, or within the
    internetworking stack element.  The functional outcome from these
    modifications would be to create a mechanism to support the use of
    multiple locators within the context of a single endpoint-to-endpoint
    session."

i am not sure that session would be appropriate for the IP layer... 
perhaps replacing session with "communication"?

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 30 Jun 2004 18:54:35 +0200

The first mail was unintentionally sent, so i include the remaining 
comments here.

- about section 4.5

I am not sure about the following comment:

   "Packet header rewriting by remote network elements has a large number
    of associated considerations, and documentation relating to the
    considerations of the use of Network Address Translators [4] contains
    much of this material."

I mean, if the multi6 layer within the host replaces the received 
locator by the ULP identifier, then it doesn't really matter the 
locator than was actually carried in the packet, right? I mean, in any 
case, the locator is transparent to the ULP which only deals with the 
identifier.

Moreover, perhaps replacing locators by identifiers introduce some of 
the nat problems, but in any case, i don't see how this  related to the 
fact that the locator is replaced by the host or by the edge router. So 
perhaps some comment like this one is required but imho is not 
restricted to this section but to all mechanisms that replace locators 
by identifiers.
Perhaps you were considering other issues here?

- about section 5.1

i fail to understand the case you are describing with:

    It is also possible to allow the endpoint identity and locator space
    to overlap, and distinguish between the two identity realms by the
    context of usage rather than by a prefix comparison.  However, this
    reuse of the locator token space as identity tokens has the potential
    to create the anomalous situation where a particular locator value is
    used as an identity value by a different endpoint.  It is not clear
    that the identity and locator contexts can be clearly disambiguated
    in every case, which is a major drawback to this particular approach.

In particular which is the difference between this case and the "home" 
locator case?

Later in this section (the last paragraph, actually) it is stated that:

    Instead of structured tokens that double as lookup keys to obtain
    mappings from endpoint identities to locator sets, the alternative is
    to use an unstructured token space, where individual token values are
    drawn opportunistically for use within a multi-homed session context.
    Here the semantics of the endpoint identity are subtly changed.  The
    endpoint identity is not a persistent alias or reference to the
    identity of the endpoint, but a means to allow the identity protocol
    element to confirm that two locators are part of the same mapped
    locator set for a remote endpoint.  In this context the unstructured
    opportunistic endpoint identifier values are used in determining
    locator equivalence rather than in some form of lookup function.

i think that it is also possible to use an unstructured identifier name 
space in a non opportunistic mode, like HIP, that supports both modes. 
I mean, the identifier in this case is persistent, but as the address 
space is not structured, lookups are at least difficult if not 
impossible in the short term.
So perhaps it would be interesting to split this paragraph in two, one 
about unstructured namespaces, and another one about using them in a 
opportunistic manner?

- in section 5.3.2

where it states that:

    One of the potential drawbacks of placing this functionality within
    the transport protocol layer is that it is possible that each
    transport protocol will require a distinct implementation of identity
    functionality.

i would add that another drawback is that some transport layers (such 
as UDP) don't have the notion of session neither, so in this case i 
guess only the app knows about sessions

- in section 5.3.3

when considering opportunistic identifiers to initiate the 
communication.
note that non of the proposals AFAIK, use opportunistic identifiers for 
the server side. imho this is very difficult, because, the client side 
needs to know the identifier in order to initiate the communication. It 
would be possible that the client side would select the servers 
identity beforehand, but this may imply collisions if the server is 
already using it. imho opportunistic ids are only suitable for clients 
(if any), but not for servers.

- section 6.1

when it states that

       Does the transport need to translate the upper level interface
       token into an identity token that identifies the session?

i guess that is not the transport who does the translation but it can 
also be the wedge layer

then when it states that

       How does the session initiator establish that the remote end of
       the session can support the multi-homing version of the transport
       protocol?

what do you mean by "the multihoming version of the transport 
protocol"? i mean in the wedge layer approach, for instance, the 
trasnport protocol is not multihoming capable, but the wedge layer is. 
I think that perhaps this section should reffer more to a multi6 
capable endpoint rather than a multi6 capable transport protocol

Additionally, i guess that i would also include in this section 
something about how does the endpoints discover the locator set 
available for the other endpoint and how do they select the source and 
destiantion locator. In other words, i think that a couple of functions 
within the fucntional decomposition should be:
* locator discovery
* locator selection (both source and destination) for initial contact

Regards, marcelo

PS: sorry for the fragmentation of the comments :-(

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 30 Jun 2004 07:47:10 -0700 (PDT)

> A network application developer actually only wants this:

The above is easy and with slight variations exist in different
higher level abstractions to access the network. I don't know if
all those abstractions do the retry loop though.

But that doesn't address UDP, which would require a different structure of the
API because only the application knows when to retry (e.g., based on the 
application layer not getting a response). Hence the retry can't be hidden
under the API for UDP.

  Erik