Subject: [rrg] 答复: Some concerns about ILNP

From: Xu Xiaohu <[email-masked]>
Date: Mon, 03 Aug 2009 17:59:15 +0800

Hi Ran, 

> At the suggestion of one of the RRG Chairs, kindly let me 
> reiterate the explanations on this topic, with specific 
> reference to the slides presented at RRG in Stockholm today.
> 
> Looking specifically at Slide 22:
> 
> 1) Off-path Attacks
>     Ordinary IPv6 without IPsec has broad vulnerability to 
> on-path attacks,
>     as noted in Slide 22, round bullet 2, triangle sub-bullet 2, first
>     dash sub-sub-bullet.
> 
>     This means that to provide equivalent security ILNP without IPsec
>     only needs to protect against off-path attacks.
> 
>     ILNP includes a Nonce to protect traffic from off-path attacks,
>     as described in Slide 22, 2nd round bullet (and its 
> subsidiary items).
> 
>     This means that ILNP without IPsec has the same security 
> properties
>     as IPv6 without IPsec.  This is also described in draft-rja-ilnp-
> nonce-*
>     and in the other draft-rja-ilnp-* drafts -- in more 
> detail than fits
>     on 1 slide in a ~30 minute overview talk.  This is also described
>     in the 2nd circular bullet on Slide 22.

Sorry, I just read your ilnp-nonce draft. I felt that without the HIP/CGA
tricks, this nonce mechanism itself only solves the session hijacking
problem, and it doesn't prevent stealing and spoofing of the identifiers.
For example, an attacker could use somebody else's identifier to initiate
communication with a given correspondent node. 

Of couse, it largely depends on the semantics of the identifier in your
ILNP. As quoted from your ilnp draft,  "Identifiers are unique within the
context of a given Locator; in many cases, Identifiers might happen to be
globally unique, but that is not a functional requirement for this proposal.
"   The related concerns are as follows:

1) Based on the assumption that the identifier is not globally unique, if
two hosts using the same identifier initiate communication with a third
host, how could this third host distinguish the different sessions from
these two hosts? 

2) Based on the assumption that the idenfiters are only needed to be unique
within the context of a given Locator, if a mobile node moved to a new
subnet, and unfortunately there is a host within this subnet which uses the
same identifier as the mobile node, should be mobile node renumber its
identifier?

3) If I understand your ILNP correctly, the DNS server will be used as the
rendezvous to deal with the simultaneous mobility issue. In pratice,
multiple hosts could share a FQDN for load-balancing purpose, that's to say,
the mapping between FQDN and I/L is 1:N, not 1:1, how could the mobile node
know which I/L is corresponding to the communicating node? Or do you believe
the DNS should be changed so that each host will have a globally unique FQDN
in your ILNP architecture?

Best regards,

Xiaohu

> 2) On-path Attacks
>     For ordinary IPv6, the only solution to on-path attacks is to use
>     IPsec (most obviously AH, but some forms of ESP could 
> also suffice).
> 
>     For ILNP, the existing solution of IPsec continues to 
> work fine, and
>     actually works *better* because IPsec for ILNP works even 
> if Locator
>     Translation ("NAT") is deployed along the path -- without 
> requiring
>     any special UDP encapsulation for "IPsec NAT Traversal".  This is
>     described in the first round bullet of Slide 22 (and its 
> subsidiary
>     items on that same slide).
> 
> Yours,
> 
> Ran
> 
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg

---

From: RJ Atkinson <[email-masked]>
Date: Mon, 03 Aug 2009 10:13:27 -0400

> communication with a given correspondent node.

It is not possible for an off-path attacker to do what you suggest
when ILNP is in use.  There is enough information available on both
ends of an ILNP session to distinguish between two different nodes
that have accidentally used the same Node Identifier.

Without repeating another paper at great length in this email,
here is a starting point to understanding:

	1) Recall that all ILNP sessions will include a
	   Nonce Destination Option sent from the initiator node
	   to the responder node (and subsequently a Nonce
	   sent from the responder to the initiator).
	2) Nonces are unidirectional, so different nonce values
	   will be used (X->Y) and (Y->X).
	
Let:
	A, B	are different initiator nodes using the same
		Node ID value.
	C	is a responder node communicating with A, B

Observe:
	1) A and B will each select large (e.g. 96-bit) Nonce
	   values independently.  If the operational risk is
	   lower, a smaller Nonce value could be selected instead.
	2) The probability of selecting the same Nonce value is now
	   1 out of 2^^96 -- this is a lower probability than selecting
	   the same inputs for generating a common CGA value.  However,
	   unlike the CGA, neither initiator nor responder need to
	   perform any significant computation -- so no new DOS attack
	   window is created by using the Nonce mechanism.
	3) Since A and B are using different Nonce values, C is
	   perfectly capable of distinguishing between A and B.
	4) As is already the case today with IPv6, it is not valid
	   to have 2 unrelated nodes on the same subnet use the
	   same Identifier (IID in the case of IPv6) value at the
	   same time.  (I say "unrelated nodes" here to distinguish
	   crisply from some kind of "distributed system" where 2
	   or more boxes form a single logical computing system.)

Note 1:	The same kind of analysis can be done to show that this
	works generally, even if A, B are responders and C is
	an initiator.  The details are omitted here because this
	is already a long email.

Note 2: None of the above mechanisms or analysis involve either
	cryptography or any other expensive mathematical operation.

	(If it is still confusing, I'd urge re-reading the published
	ILNP papers and also the ILNP Internet-Drafts to gain more
	clarity on this.)

Finally, if some folks want to use CGAs, that is fine.  ILNP permits
the existing CGA specifications to be used without any modification.
Again, we've shown that ILNP has security properties no worse than IPv6.

> host, how could this third host distinguish the different sessions  

Please see above.  There is sufficient other information to distinguish
the sessions from each other.  This is discussed in more depth in
other published drafts/documents.

> same identifier as the mobile node, should be mobile node renumber its

If the node wanted to change its Identifier, it could do so without  
losing
any existing sessions.

However, kindly recall IPv6.  The IPv6 rules say that a given IID
must be unique within the context of a specific /64 routing prefix.

The ILNP rule is not more strict than the IPv6 rule.  So again,
ILNP does not fail to support any case that works today with IPv6.

In normal operation, the ILNP Identifier would probably be an EUI-64
with the scope bit set to "global" and would be formed by using some
EUI-48 or EUI-64 already associated with the node.  Recall this also
is entirely consistent with IPv6 practices on forming an IID.  In
this case, the IEEE allocation rules combined with the EUI-64
formation rules ensure that the scenario you describe will not occur.

In some different case where an ILNP Identifier is being formed in
some other way (e.g. some pseudo-anonymous ID algorithm), then as
with IPv6 some form of DAD would be required because the scope bit
is set to "local".  ILNP never requires that a node use this form
of Identifier, although a node might choose to do so if it wishes.

So one can again see that ILNP is imposing no new constraints beyond
those imposed by IPv6 at present, and that deployments that work
today with IPv6 would also seamlessly work with ILNP.

Of course, ILNP provides various benefits (described throughout
the talk and the various drafts/documents) that IPv6 does not provide.
So there is a net benefit to migrating to ILNP from ordinary IPv6.

> in your ILNP architecture?

In the scenario you describe, existing deployments of that kind
share session state among the N physical boxes that are clustered
to emulate a single node.

That is, the case you describe is not really a case of N separate nodes,
but instead it is the case of a single distributed system that happens
to be built out of a number of boxes.  This sort of clustering has been
commonplace for decades.  (I think I first encountered it with a DEC
VAX/VMS cluster.  One imagines modern systems are most commonly built
out of some flavour(s) of UNIX.)

Moreover, in such cases in the real-world today, multiple "back end"
servers are fronted by some commercial load-balancing appliance.  Those
appliances ensure that requests are handled consistently by the server
cluster.  Various session management mechanisms have been built by
various commercial vendors, but they all have the same apparent
external behaviour (i.e. from the perspective of the client system).

No DNS changes are needed for ILNP, other than adding the I and L  
records.
Optionally, also adding the LP record optimises DNS performance and
scalability for mobile network cases or for site multi-homing cases.

Yours,

Ran

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 04 Aug 2009 09:50:47 +0800

Hi Ran,

> > Sorry, I just read your ilnp-nonce draft. I felt that without the 
> > HIP/CGA tricks, this nonce mechanism itself only solves the session 
> > hijacking problem, and it doesn't prevent stealing and 
> spoofing of the 
> > identifiers.
> > For example, an attacker could use somebody else's identifier to 
> > initiate communication with a given correspondent node.
> 
> It is not possible for an off-path attacker to do what you 
> suggest when ILNP is in use.  There is enough information 
> available on both ends of an ILNP session to distinguish 
> between two different nodes that have accidentally used the 
> same Node Identifier.
> 
> Without repeating another paper at great length in this 
> email, here is a starting point to understanding:
> 
> Finally, if some folks want to use CGAs, that is fine.  ILNP 
> permits the existing CGA specifications to be used without 
> any modification.

Without any modification? in the current CGA specification [RFC3972], the
prefix is used as one of the inputs for the hash algorithms. If the subnet
prefix (locator in ILNP) changed due to mobility or multihoming event,
should the identifier be regenerated? If so, it seems conflict with the
statement of "constant identifier as node move " in your slides. 

As mentioned in the CGA specification, if the prefix is not included in the
generating algorithm, the security strength will be weaken (see the
following quoted statement ).

  " As computers become faster, the 64 bits of the interface identifier
   will not be sufficient to prevent attackers from searching for hash
   collisions.  It helps somewhat that we include the subnet prefix of
   the address in the hash input.  This prevents the attacker from using
   a single pre-computed database to attack addresses with different
   subnet prefixes.  The attacker needs to create a separate database
   for each subnet prefix."

Due to the above reasons, in my RANGI proposal (called HRA previously,
http://www.ietf.org/id/draft-xu-rangi-01.txt), the Administrative Domain
(AD) ID replaces the routing prefix as one of the inputs for generating host
identifiers. The AD ID is stable and will remain constant during mobility
and multihoming.

> > 1) Based on the assumption that the identifier is not 
> globally unique, 
> > if two hosts using the same identifier initiate 
> communication with a 
> > third host, how could this third host distinguish the different 
> > sessions from these two hosts?
> 
> Please see above.  There is sufficient other information to 
> distinguish the sessions from each other.  This is discussed 
> in more depth in other published drafts/documents.

Then you must make some change to the session. e.g., extending the 5 tuples
of TCP session to 6 tuples.

> > 2) Based on the assumption that the idenfiters are only 
> needed to be 
> > unique within the context of a given Locator, if a mobile 
> node moved 
> > to a new subnet, and unfortunately there is a host within 
> this subnet 
> > which uses the same identifier as the mobile node, should be mobile 
> > node renumber its identifier?
> 
> If the node wanted to change its Identifier, it could do so 
> without losing any existing sessions.

Really? since the sessions are bound to identifiers, wouldn't the sessions
be disrupted by changing the identifiers?

> However, kindly recall IPv6.  The IPv6 rules say that a given 
> IID must be unique within the context of a specific /64 
> routing prefix.

Yes, but the rules do not say the IID must be unique globally. Hence, there
is a possiblity that two nodes located in different subnet use the same IID
(i.e., identifier in ILNP)
 
> The ILNP rule is not more strict than the IPv6 rule.  So 
> again, ILNP does not fail to support any case that works 
> today with IPv6.

Not exactly. IPv6 uses the combination of routing prefix+IID as session
identifier, and this idenfier ought to be unique globally. However, in ILNP,
the IID part is used as identifier, which is not globally unique.
 
> In normal operation, the ILNP Identifier would probably be an 
> EUI-64 with the scope bit set to "global" and would be formed 
> by using some
> EUI-48 or EUI-64 already associated with the node.  Recall 
> this also is entirely consistent with IPv6 practices on 
> forming an IID.  In this case, the IEEE allocation rules 
> combined with the EUI-64 formation rules ensure that the 
> scenario you describe will not occur. 
> In some different case where an ILNP Identifier is being 
> formed in some other way (e.g. some pseudo-anonymous ID 
> algorithm), then as with IPv6 some form of DAD would be 
> required because the scope bit is set to "local".  ILNP never 
> requires that a node use this form of Identifier, although a 
> node might choose to do so if it wishes.
> 
> So one can again see that ILNP is imposing no new constraints 
> beyond those imposed by IPv6 at present, and that deployments 
> that work today with IPv6 would also seamlessly work with ILNP.
> 
> Of course, ILNP provides various benefits (described 
> throughout the talk and the various drafts/documents) that 
> IPv6 does not provide.
> > 3) If I understand your ILNP correctly, the DNS server will 
> be used as 
> > the rendezvous to deal with the simultaneous mobility issue. In 
> > pratice, multiple hosts could share a FQDN for 
> load-balancing purpose, 
> > that's to say, the mapping between FQDN and I/L is 1:N, not 
> 1:1, how 
> > could the mobile node know which I/L is corresponding to the 
> > communicating node? Or do you believe the DNS should be changed so 
> > that each host will have a globally unique FQDN in your ILNP 
> > architecture?
> 
> In the scenario you describe, existing deployments of that 
> kind share session state among the N physical boxes that are 
> clustered to emulate a single node.
> 
> That is, the case you describe is not really a case of N 
> separate nodes, but instead it is the case of a single 
> distributed system that happens to be built out of a number 
> of boxes.  This sort of clustering has been commonplace for 
> decades.  (I think I first encountered it with a DEC VAX/VMS 
> cluster.  One imagines modern systems are most commonly built 
> servers are fronted by some commercial load-balancing 
> appliance.  Those appliances ensure that requests are handled 
> consistently by the server cluster.  Various session 
> management mechanisms have been built by various commercial 
> vendors, but they all have the same apparent external 
> behaviour (i.e. from the perspective of the client system).

Yes, I know the load-balancing can be done by some applications. However, we
shouldn't exclude the possibility of using DNS to realize the same goal.

Best regards,

Xiaohu
 
> No DNS changes are needed for ILNP, other than adding the I 
> and L records.
> Optionally, also adding the LP record optimises DNS 
> performance and scalability for mobile network cases or for 
> site multi-homing cases.
> 
> Yours,
> 
> Ran
>

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 04 Aug 2009 10:16:03 +0800

> > distinguish the sessions from each other.  This is 
> discussed in more 
> > depth in other published drafts/documents.
> 
> Then you must make some change to the session. e.g., 
> extending the 5 tuples of TCP session to 6 tuples.

Or maybe you can use a redirection mechanism to avoid this change. e.g.
mapping the combination of source identifier+nonce to a locally unique
identifier which is assigned by the host.

Xiaohu

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 04 Aug 2009 09:13:04 -0400

On  3 Aug 2009, at 21:50, Xu Xiaohu wrote:
> in the current CGA specification [RFC3972], the

It is not required that ALL Identifiers used by a node remain constant.
It is helpful if at least one Identifier does remain constant, at least
for the duration of a given session.

I'd really suggest studying the ILNP papers and I-Ds once again.

> identifiers. The AD ID is stable and will remain constant during  

I haven't read your proposal, so I can't comment on it.

> of TCP session to 6 tuples.

Your sentence above is not clear.

What I can say is that ILNP doesn't break anything.  ILNP is not  
identical
to IPv6, particularly in that they have somewhat different  
architectures.
ILNP does provide a superset of IPv6 capabilities in an IPv6 friendly  
way.

> Since the sessions are bound to identifiers, wouldn't the sessions

No.  ILNP already supports a node having more than one valid
Identifier at a given point in time.

> (i.e., identifier in ILNP)

That case was discussed at length yesterday.  ILNP does not have
a problem with 2 nodes accidentally using the same Node ID with
different Locator values.

> the IID part is used as identifier, which is not globally unique.

PLEASE go re-read the ILNP document set.  ILNP requires that a Node ID
is unique *within the context of a given Locator*.  ILNP does not  
require
that a Node ID be globally unique.

> However, we shouldn't exclude the possibility of using DNS to  
> realize the same goal.

ILNP doesn't exclude that.

PLEASE go re-read the ILNP document set.  It is pretty clear
that you haven't read it recently, from your several points of
confusion.

Yours,

Ran
[email-masked]

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 05 Aug 2009 09:13:26 +0800

Hi Ran,

In fact, my question is much simple, that is: when a mobile node moves to a
new subnet where another node occasionally uses the same identifer as the
mobile node, should the mobile node renumber its identifier? if so, can the
established session using that identifier survives after idenfifier
renumbering? if not, how could the last-hop router distinguishes these two
hosts when forwarding packets destined to one of them?

Could you please tell me in which I-D and which section the above question
has been answered. Thus I can find the answer quickly. Thanks.

Best regards,

Xiaohu

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 RJ
Atkinson
> 发送时间: 2009年8月4日 21:13
> 收件人: IRTF Routing RG
> 主题: Re: [rrg] Some concerns about ILNP
> 
> 
> > in the current CGA specification [RFC3972], the prefix is 
> used as one 
> > of the inputs for the hash algorithms. If the subnet prefix 
> (locator 
> > in ILNP) changed due to mobility or multihoming event, should the 
> > identifier be regenerated? If so, it seems conflict with 
> the statement 
> > of "constant identifier as node move " in your slides.
> 
> It is helpful if at least one Identifier does remain 
> constant, at least for the duration of a given session.
> 
> > (AD) ID replaces the routing prefix as one of the inputs for 
> > generating host identifiers. The AD ID is stable and will remain 
> > constant during mobility and multihoming.
> 
> What I can say is that ILNP doesn't break anything.  ILNP is 
> not identical to IPv6, particularly in that they have 
> somewhat different architectures.
> ILNP does provide a superset of IPv6 capabilities in an IPv6 
> friendly way.
> 
> > Since the sessions are bound to identifiers, wouldn't the 
> sessions be 
> > disrupted by changing the identifiers?
> 
> > is a possiblity that two nodes located in different subnet use the 
> > same IID (i.e., identifier in ILNP)
> 
> That case was discussed at length yesterday.  ILNP does not 
> have a problem with 2 nodes accidentally using the same Node 
> ID with different Locator values.
> 
> > Not exactly. IPv6 uses the combination of routing prefix+IID as 
> > session identifier, and this idenfier ought to be unique globally. 
> > However, in ILNP, the IID part is used as identifier, which is not 
> > globally unique.
> 
> PLEASE go re-read the ILNP document set.  ILNP requires that 
> a Node ID is unique *within the context of a given Locator*.  
> ILNP does not require that a Node ID be globally unique.
> 
> > However, we shouldn't exclude the possibility of using DNS 
> to realize 
> > the same goal.
> 
> that you haven't read it recently, from your several points 
> of confusion.
> 
> Yours,
> 
> Ran
> [email-masked]
> 
>

---

From: Tony Li <[email-masked]>
Date: Tue, 04 Aug 2009 21:25:30 -0700

Let me see if I can answer:

> mobile node, should the mobile node renumber its identifier? 

Simply put: this needs to never happen.  That creates the potential for
a collision within the same locator.  It's up to the administrator of
that local subnet to ensure that there's some mechanism for resolving
this.  Note that it does not mean that the mobile node much change its
identifier, just that it needs to not use that identifier while the
other node could possibly appear.

One alternate approach would be for it to have a temporary, local
identifier purely for use within that subnet.

Or, there can be some mechanism that prevents the other node from
connecting.

> if so, can the
> renumbering? 

Certainly.  Again, the identifier does not need to be abandoned.  The
only restriction is that there are not two systems with the same locator
 and same identifier at the same time.

For example, if a node is going to make use of the temporary identifier
that I hallucinated above, then it could return to its permanent
identifier when it leaves the locator where there's a conflict.  If the
timing permits, the session can continue.

> if not, how could the last-hop router distinguishes these two

The last-hop router might well distinguish the two based on the link
layer address and knowing which one is active at present.

> has been answered. Thus I can find the answer quickly. Thanks.

This is all in the base ILNP spec.

Tony

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 05 Aug 2009 13:26:41 +0800

Hi Tony,

> -----邮件原件-----
> 发件人: Tony Li [mailto:[email-masked]] 
> 发送时间: 2009年8月5日 12:26
> 收件人: Xu Xiaohu
> 抄送: 'RJ Atkinson'; 'IRTF Routing RG'
> > In fact, my question is much simple, that is: when a mobile 
> node moves 
> > to a new subnet where another node occasionally uses the same 
> > identifer as the mobile node, should the mobile node 
> renumber its identifier?
> 
> 
> Simply put: this needs to never happen.  That creates the 
> potential for a collision within the same locator.  It's up 
> to the administrator of that local subnet to ensure that 
> there's some mechanism for resolving this.  Note that it does 
> not mean that the mobile node much change its identifier, 
> just that it needs to not use that identifier while the other 
> node could possibly appear.
> 
> One alternate approach would be for it to have a temporary, 
> local identifier purely for use within that subnet.
> 
> Or, there can be some mechanism that prevents the other node 
> from connecting.

Do you mean if there is an identifiier collision during mobility, one should
be killed even though it is communicating with somebody else?
 
> Certainly.  Again, the identifier does not need to be 
> abandoned.  The only restriction is that there are not two 
> systems with the same locator  and same identifier at the same time.
> 
> For example, if a node is going to make use of the temporary 
> identifier that I hallucinated above, then it could return to 
> its permanent identifier when it leaves the locator where 
> there's a conflict.  If the timing permits, the session can continue.

If a mobile node change the session association from its permenant id to its
temperary id, the session is broken.

> > if not, how could the last-hop router distinguishes these two hosts 
> > when forwarding packets destined to one of them?
> 
> 
> The last-hop router might well distinguish the two based on 
> the link layer address and knowing which one is active at present.

Before distinguishing the two identities, how could the last-hop router
determine which node a given link layer address is corresponding to? It seem
like a egg-chicken issue.

> > Could you please tell me in which I-D and which section the above 
> > question has been answered. Thus I can find the answer 
> quickly. Thanks.
> 
> 

Thanks, I will read it carefully.

Best regards,

Xiaohu

---

From: Tony Li <[email-masked]>
Date: Tue, 04 Aug 2009 22:34:31 -0700

One more time, with feeling...

> be killed even though it is communicating with somebody else?

No, we're saying that it is the administrator's responsibility to ensure
that there is no identifier collision.

> temperary id, the session is broken.

No, there is no provision to change the identifier that a particular
transport connection is associated with.

> like a egg-chicken issue.

Not at all.  Suppose that we have identifier I, and two link layer
addresses, A1 and A2.  Suppose that the router has a binding in its
neighbor cache for (I, A1), but that this entry has reached the point of
being stale.  Now, the router sees a packet (e.g., ND - RS) for (I, A2).
 It's well within the router's purview to now make use of this association.

Tony

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 05 Aug 2009 06:56:52 -0400

> mobile node, should the mobile node renumber its identifier?

First, if the mobile node is thoughtful, the mobile node will be using
an Identifier value based on an IEEE MAC address.  In such a case,
the scenario you describe will never occur.

Why is such a non-realistic scenario interesting ?

> if so, can the established session using that identifier survives
> after idenfifier renumbering?

Yes.

> when forwarding packets destined to one of them?

Now, if the mobile node is NOT using an Identifier value based on an
IEEE MAC address, then the "scope" bit in the Identifier will be set
to "local scope" and so the usual IPv6 Duplicate Address Detection (DAD)
is used.

This use of IPv6 DAD ensures that only one node can possess the same
Identifier value at a given time on a given IPv6 subnet.  Of course,
there is a 1:1 mapping between a 64-bit Locator value and an IPv6
subnet.

> question

draft-rja-ilnp-intro-02.txt addresses this in several different places.

draft-rja-ilnp-nonce-01.txt is also relevant in several places, for
example the definition of the Correspondent Cache in Section 5.2 where
all Identifiers for each correspondent node are kept inside the cache.

draft-rja-ilnp-dns-01.txt is also relevant in several places, for
example Section 2.2 defines the semantics and syntax of I records.

As with the BGP RFC, the ILNP drafts are protocol specifications,
rather than tutorials.  An implementer ought to read them as a set.

Yours,

Ran
[email-masked]

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 05 Aug 2009 07:13:01 -0400

> transport connection is associated with.

Just as a clarification, in case tli's comment above doesn't get
parsed/lex'd correctly,...

It is important to recall that a node is permitted to have multiple
Identifiers concurrently, and that correspondents cache *all* of the
Identifier values.  So a node A could switch from an Identifier (I1)
that collided to a different Identifier (I2) that belonged to that
same node A, and the session can stay up when such a change occurs.

Yours,

Ran

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 06 Aug 2009 09:49:32 +0800

> Just as a clarification, in case tli's comment above doesn't 
> get parsed/lex'd correctly,...
> 
> It is important to recall that a node is permitted to have 
> multiple Identifiers concurrently, and that correspondents 
> cache *all* of the Identifier values.  So a node A could 
> switch from an Identifier (I1) that collided to a different 
> Identifier (I2) that belonged to that same node A, and the 
> session can stay up when such a change occurs.

Interesting, then the SHIM6 mechanism or parts of it should also be
involved.

Xiaohu

---

From: Tony Li <[email-masked]>
Date: Wed, 05 Aug 2009 19:54:01 -0700

> Interesting, then the SHIM6 mechanism or parts of it should also be

Sorry, I'm not following you.  Why are you suggesting that any part of 
SHIM6 be involved?

Tony

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 06 Aug 2009 05:05:31 -0400

On  5 Aug 2009, at 21:49, Xu Xiaohu wrote:
> Interesting, then the SHIM6 mechanism or parts of it
> should also be involved.

ILNP is independent from SHIM6.

Ran