Subject: [Q] Routing header

From: "Jiwoong Lee" <[email-masked]>
Date: Thu, 24 May 2001 09:25:02 +0900

I found only one type of routing header is given in the IPv6 spec.

I've got two simple questions:

1) Are there other kinds of routing header type defined in documents ?
2) If any, Is it possible to include multiple routing headers at the same 
time with different routing header type ?

Regards,

Jiwoong

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: IMAI Yuji <[email-masked]>
Date: Fri, 25 May 2001 06:52:04 +0900

Hi, Jiwoong.

You can find IANA already assigned one more type of routing
header looking at
http://www.isi.edu/in-notes/iana/assignments/ipv6-parameters

I am not sure but there was no consderation we can attach more
than two routing header in a datagram.
---
Yuji

From: "Jiwoong Lee" <[email-masked]>
Subject: [Q] Routing header
Date: Thu, 24 May 2001 09:25:02 +0900

---

From: "Jiwoong Lee" <[email-masked]>
Date: Fri, 25 May 2001 17:14:52 +0900

Thanks for the information Yuji.

One interesting thing to me about routing header specified in rfc 2460, is
that the spec descrbies that the routing header itself, rather than routing
header with type 0 is similar
to loose source route option in IPv4. What is missing (I think) in the spec
is, description on possiblities of plural routing headers with different
types or the same types.

PS, Please, would anyone notify me of the reliable delivery of this message
? It seems the majordomo does not like this email very much - it spat out.

---

From: Steve Deering <[email-masked]>
Date: Tue, 29 May 2001 12:40:26 -0700

>1) Are there other kinds of routing header type defined in documents ?

There was a draft proposal for another type of routing header at one time,
but I don't think anyone is pushing it at the moment.

>time with different routing header type ?

Yes, it is permitted for a single packet to carry multiple routing headers,
either of the same type or different types, though I would expect that
to happen very rarely, if ever.  (In other words, an IPv6 node must be
prepared to handle such a case properly, but need not optimize its
performance.)

Steve

---

From: Steve Deering <[email-masked]>
Date: Tue, 29 May 2001 12:52:18 -0700

At 5:14 PM +0900 5/25/01, Jiwoong Lee wrote:
>What is missing (I think) in the spec is, description on possiblities of
>plural routing headers with different types or the same types.

The last paragraph of section 4.1 discusses the general issue of
extension headers appearing more than once in the same packet.
As far as I know, there is no reason for giving special consideration
to multiple Routing headers, and the required left-to-right processing
order for all extension headers makes the semantics of multiple Routing
headers unambiguous, I believe.

Steve

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 May 2001 13:03:44 -0700 (PDT)

> headers unambiguous, I believe.

   Where there is ambiguity, however, is in the host's construction
   of the routing header. Consider the situation where you have a
   mobile host behind a mobile router, each of which send binding
   updates to a correspondent node. How does the correspondent
   node know which order to put the routing headers in?

	     Mike

---

From: Steve Deering <[email-masked]>
Date: Tue, 29 May 2001 13:31:30 -0700

>   node know which order to put the routing headers in?

Mike,

You'll have to spend more time educating me on the details of the
scenario you have in mind.  I would hope and expect that some
encapsulation/decapsulation is going on at the mobile router,
in which case you might have one routing header as part of the
inner (encapsulated) packet, and one routing header as part of
the outer (encapsulating) packet, which is a different case than
having multiple routing headers in a single extension-header
chain.  I was assuming the question applied to the latter case,
though the semantics of encapsulation case is also obvious.

How you decide when to include a routing header and what to put in
it are questions largely unanswered by the IPv6 specs (as is the
case with source routes in IPv4).  We just provide the primitive;
it's up to others to write the programs to use it.  I guess Mobile
IPv6 has done that for one case (though I *really* wish they had
specified the use of encapsulation instead of extension-header-
insertion; that would have eliminated *much* ambiguity and confusion).
In the absence of such specs, the Routing header contents will just
continue to be provided manually, as in source-routed pings and
traceroutes.

Steve

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 May 2001 14:11:47 -0700 (PDT)

Steve Deering writes:
 > the outer (encapsulating) packet,

   I don't think there are any answers for this at 
   within mipv6.

 > which is a different case than

   This is mostly a mipv6 issue, but suppose you have:

   MN------->MR------------------------>CN

   When the mobile node moves, it sends a BU to the CN.
   When the mobile router moves, it too sends a BU to the CN.

   The CN now has a binding entry for both the mobile node
   and the mobile router in its cache. Now if this
   is going to work at all (which I think is the $64 
   "if") CN would need to construct a packet like:

    IP: dst=CoA(mr); RH: dst=CoA(mn); RH: dst=Home(mn);

   to prevent the packet from going through the
   home agent of either the MN or MR.

   Yet, MN and MR might know nothing about each
   other (the general case, I'd think) and CN
   doesn't have any clue about the far end
   topology either. It just has two binding 
   entries in its binding cache with no way
   to correlate them, let alone set the proper
   ordering.

 > continue to be provided manually, as in source-routed pings and

   Yes, I should make it clear that this isn't a
   ipng ambiguity.

		Mike

---

From: Steve Deering <[email-masked]>
Date: Tue, 29 May 2001 14:26:21 -0700

>   I don't think there are any answers for this at 

Last time I looked, the Mobile IPv6 spec dealt with mobile hosts only,
not mobile routers.  If that's still true, it's unsurprising that
it doesn't handle your scenario -- that would be the responsibility
of a (future) Mobile IPv6 Router spec.

>   to correlate them, let alone set the proper

Presumably, to make this work, the BU from the mobile router to the CN
would have to include the address prefix(es) reachable via the mobile
router (i.e., the mobile subnet or larger aggregate that the mobile
router is supposed to serve).  With that info, the CN would be able to
tell that the mobile host address falls within the address block served
by the mobile router, and could build the necessary header chain.

Steve

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 29 May 2001 23:48:39 +0200

Hi all,

I have cc to the MIP WG because I think this discussion falls in its
interest.

>    I don't think there are any answers for this at

This case was never really considered so far in any of the MIP specs. 
There is no answer to this specific case for the reason that mobile
networks are not explicitly addressed in any of the WG specs (indeed,
HMIPv6 which is a WG item does have a word about this and in this case
the CN wouldn't endup with 2 BUs).
 
>    When the mobile router moves, it too sends a BU to the CN.

This is only your scenario.   You could think of any scenario you want. 
Anyway, this is something I have already raised in the MIP WG and this
is presumably a case where MIPv6 would fail.

>    "if") CN would need to construct a packet like:

But, first, why should the CN get two BUs ?  The CN is not a CN for the
MR.      Unless you refer to my draft 
http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt
which proposes that the MR be in charge of all the mobility management
of the mobile network.  But this is just a proposition, and it mainly
focus on the case where the nodes behind the router wired and fixed
nodes, not mobile nodes.

Then, your issue is rather a proposal for a solution, and it would be
better if you could first specify your solution, this would highly
highlight the issue you are trying to discuss.

--
* mailto:[email-masked]  Tel +33 (0) 4 76 61 52 69 
* INRIA Rhone-Alpes Projet PLANETE       (fax 52 52) 
* and MOTOROLA Labs Paris
* http://www.inrialpes.fr/planete/people/ernst/Welcome.html
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 29 May 2001 23:54:53 +0200

> of a (future) Mobile IPv6 Router spec.

Steve, you are perfectly right - mobile routers and networks is not yet
a MIP WG item and the charter has never pretended to address this
issue.  May be it's time for it now.  What does the MIP WG think about
this ?  Any vote for it to be included in the charter for the next
meeting ?

> by the mobile router, and could build the necessary header chain.

This is basically what my draft is proposing.  And in this case, the
MIPv6 spec needs redefine the "CN Operation".
(all is in the draft
http://www.inrialpes.fr/planete/people/ernst/Documents/draft-ernst-mobileip-v6-network.txt)

But there is an authorization issue that needs to be addressed as
everyone knows. 

Thierry.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 29 May 2001 15:53:53 -0700 (PDT)

> is presumably a case where MIPv6 would fail.

   I'm aware that this is only my scenario, but this is
   what I think a naive implementation would do. Ie,
   the mobile router would think it's supposed to send
   a BU when it see something come in from its home agent
   tunnel interface, the MN (or another MR) would
   think it's supposed to send a BU...

 > MR. 

   If the MR subtends a prefix and can send a BU
   which is legal in -13 as you know, it would 
   send a BU when it sees the packet on the HA
   interface. Otherwise, you'd have triangular
   routing at the MR.

     Unless you refer to my draft 
 > of the mobile network.

   Well, I think that we probably need to look at
   the induction from 1 to n otherwise the
   diagrams keep getting harder to parse each
   time we have to go through this :-)

 > highlight the issue you are trying to discuss.

   I'm not trying to propose anything, actually. I'm just
   pointing out that the current set of drafts won't
   work as they are currently stated to more than
   one level of mobility.

	     Mike

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 31 May 2001 13:53:36 +0200

>    think it's supposed to send a BU...

I agree that a MN behind the MR is supposed to send a BU, but I disagree
that the MR "is supposed to" do it as well.   First, the MR is not the
final destination of the packet.  Second, if you think about a naive
implementation, MR would send a BU to the sender that appears in the
inner header in the encapsulated packet, i.e. the CN of MN "behind"
MR.   And what would contain the BU ?  A binding between the MR's home
address and its COA.   This does not give much usefuk information to the
CN.  You would end up with a cache at the CN containing:

MR home address -> MR coa
MN home address -> MN coa

CN uses MR's coa if it ever want to communicate with MR directly (very
unlikely)
CN uses MN's coa for packets it wants to send to the MN.      No problem
at the CN, although your datagram is going to be routed via the MR's HA
(because MN's coa has the same prefix has the MR's home address.   The
issue is that the HA does not know how to redirect  (same reason as
explained in my draft)

Then, the issue your are describing (including two addresses in the
routing header) would not happen with a naive implementation of MRs.  
If any proposal would advocate such use of the routing header, I think
it should also describe how this should be done.

>    which is legal in -13 as you know,  it would

Sorry, I don't catch you here. Could you refine ?

>    work as they are currently stated to more than

This is right, but this is not the purpose of any existing draft to
address more than one level of mobility.   More than one level of
mobility needs it's own set of drafts.

Thierry.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 31 May 2001 09:59:12 -0700 (PDT)

Thierry Ernst writes:
 > that the MR "is supposed to" do it as well.   

   If this is true, what is the purpose of putting a subnet prefix
   into the BU at all? How does the MR (ignoring MN for the moment)
   eliminate triangular routing through its HA? Surely the purpose
   of adding the prefix wasn't just to say that MN was reachable
   at a range of IP addresses.

 > First, the MR is not the
 > CN.  

   Remember it's the MR's home _prefix_, not address. That's
   what my reference to the -13 draft was about below. 

 > it should also describe how this should be done.

   I think the problem here is that the addition of prefix
   to the BU is not sufficient to support mobile routers,
   and as such it's open to interpretation what the
   implementation should do.

   While I generally like the addition of subnet prefix
   to BU's (mainly because it treats BU's like the routing
   updates that they are), it may actually be better to
   get the MIP WG to take the whole subject of MR's up
   as working group item and delete it till then because
   it may unfairly prejudice the final outcome.

	  Mike

---

From: Thierry Ernst <[email-masked]>
Date: Thu, 31 May 2001 19:56:04 +0200

>    what my reference to the -13 draft was about below.

Mickael,

You might probably not read the mipv6-13 draft correctly.   The purpose
of the home_prefix in the MIPv6 spec. is for the Home Agent to defend
ALL home addresses of the MN on the home link (link local, site local,
global), not for support of Mobile Routers.    This has ab-so-lu-te-ly
nothing to do with the Mobile Router case.   If it has, may be I should
rather going to grew vegetables or follow English lessons (don't know
which one would be the best though :-)

The prefix you are refering to is therefore included by the MN to inform
its HA (not its CNs) [remember the 'H' bit that stands for 'Home
Registration" ?] about the size of the prefix, not to manage mobile
routers and networks.   In addition, whatever the mobile (host or
router), a binding is ALWAYS established between the 128-bits Home
Address of the mobile and it's 128-bits Careof Address.   The only place
were is mentioned a binding between a prefix and a 128-bits address is
my draft.  Otherwise, the contribution of my draft would be pointless. 
Why should I introduce a new sub option if there is already all we need
in the MIPv6-13 draft ? 
 
>    implementation should do.

IMHO, there is nothing to miss-interpret since the addition of prefix in
the BU is not in the MIPv6-13 draft.  What may be miss-interpreted by
implementation is redirection at the HA of packets intended to nodes
behind the MR (problem described in my draft - sorry, I always refer to
my draft, but I do not want to explain everything in each email and this
is clearly described there)
 
On the other hand,  I advocate that my draft may be miss-intrepreted,
but this is only version-1 and I clearly stated that my proposal does
not consider MN behind the MR (BTW, I did state this exaclty for the
reason you were describing at the beginning of this thread - what would
the CN do with 2 BUs, one from MN, and one from MR)

>    as working group item 

This is exactly what many people already want (to list just a few of
them Hesham Soliman, Francis Dupont, Claude Castelluccia, Glenn Morrow,
and may others).   May be I should ask for it more explictly.

> and delete it till then because

And delete it ?  Sorry, I do not understand.   (may be I should really
take English lessons then :-)

There is a problem with mobile routers because this special case has
never been considered seriously (or not at all) in any of the existing
MIP WG specs.   My interpretation is that implementers should only
implement the MIP WG drafts for hosts.  Another set of specs. is
required for mobile routers.

Thierry.