Subject: [nemo] Editorial comments from Jari Arkko

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 01 Dec 2003 18:07:26 -0800

hi Jari,

thanks for the detailed review.

>              Network Mobility (NEMO) Basic Support Protocol
> 
> JARI: Why "Basic Support"? Wouldn't Network Mobility Base
>       Protocol be a sufficient name for this?
> 

well, the term was in use before this draft was written. infact
it is used in the charter. "Extended Support" talks about route
optimization for the nodes in the mobile network. the WG has a
charter item to look into Extended Support and define
requirements.

> JARI: I think LFNs can be complete mobility-unaware, I think you
>       should mention this upfront as one of the benefits.

LFNs by definition are nodes which are not mobility aware. they
are fixed nodes. we already mention this once in the abstract
itself.

    The protocol is designed
    in such a way that network mobility is transparent to the nodes
    inside the mobile network.

> JARI:  Hmm... there might be value in defining the terms in a self-contained
>        manner here. I'm pretty sure you only use a subset of [8] terms,
>        so it wouldn't be that long.

I also believe in a document being self contained when it comes
to terminology. but there is a separate WG document on NEMO
terminology that is being advanced as an informational RFC. so
I am not sure.

>       Prefix Table
> 
>               It is a list of a Mobile Network Prefixes indexed
>               by the Home Address of a Mobile Router.  The prefix table
>               is managed by the Home Agent and is used by the Home Agent
>               to determine which Mobile Network Prefixes are owned
>               a particular Mobile Router.  This is an optional data
>               structure.
> 
> JARI: Really? Why is it optional? Sounds mandatory to me...

well, there could be scenarios where the mobile routers are not
expected to misbehave. and there could be other ways for verifying
this. so we left it optional. I dont mind making it mandatory.

>    A Mobile Network is a network segment or subnet which can move
>    and attach to arbitrary points in the Internet.  A Mobile Network
>    does not allow any transit traffic and can only be accessed via
>    specific gateways called Mobile Routers that manage its movement.
> 
> JARI: The above is a bit unclear. I think you mean that the
>       nodes behind the MR can't access the internet directly, they
>       have to go through the MR and the HA.

actually no. it means traffic to the Mobile Network can reach
the Mobile Network only through mobile routers. it also says
mobile networks are not transit networks. always stub networks.

> JARI: Question: is the prefix for a MR always unique? This seems unclear.
>       Can other MRs have the same prefix, can the HA have the same
>       prefix as the MR?
> 

more than one MR can be assigned a prefix. one can imagine having
two routers for the same mobile network. the HA will probably not
have the same prefix as the MR.

> JARI: Come to think of it, both the MR and the HA must know the
>       assigned prefixes beforehand in any case, so I wonder if we
>       need to communicate the prefixes at all?!? Can you cite an
>       example where the HA would give a prefix to the MR without
>       knowing it belongs to it? Or is the idea to prepare for the
>       eventual bootstrapping support in MIPv6?

well, we still havent figured out how to do prefix delegation
to a mobile router. there is a draft by Ralph Droms on extending
DHCPv6 prefix delegation for NEMO. not a WG draft yet.

and there is this scenario, where the mobile router is delegated
more than prefix, but it could decide to setup forwarding for just
one prefix instead of all prefixes. this cant be dont without
carrying prefix information in the Binding Update.

> JARI: So, presumably this includes forwarding of packets to
>       the MR's own home address under all these prefixes, no?
>       If so, I think we have the S=0 bit functionality when you
>       set R=1 ;-)

:) only if the mobile router has configured all its home addresses
from its MNPs.

> JARI: Is there something that you would perhaps like to 
>       reference from MIPv6 regarding this tunneling, or is [3] enough?
> 

why? are we missing something.

>    Finally, the Home Agent may be configured with static routes to the
>    Mobile Network Prefix via the Mobile Router's Home Address.  In that
>    case, the routes are set independently of the binding flows and the
>    returning Home of a Mobile Router.  The benefit is that such movement
>    does not induce any additional signalling in the form of routing
>    updates in the Home Network.  The drawback of that model is that the
>    routes are present even if the related Mobile Routers that are not
>    reachable (at Home or bound) at a given point of time.
> 
> 
> JARI: This is only a drawback if the routes would be reachable somewhere
>       else. Given the desire to keep the Internet routing pretty
>       stable, I would argue that we shouldn't be moving routes all
>       over the place. Hence it would be sufficient if the routes
>       were on one place only.

well, its a drawback in the sense, the Home Agent has routing table
entries even though the mobile router is currently dormant or just
disconnected.

> JARI: What happens in the statically configured route case if R=0?
>       Reading on...

there are two static cases.

1. implicit mode
2. dynamic routing protocol updates

which one are you referring to?

>    This document introduces a new Prefix Information field in the
>    Binding Update list structure.  This field is used to store any
>    prefix information that the Mobile Router includes in the Binding
>    Update.  If the Mobile Router sets the Mobile Router flag 'R' in the
>    Binding Update, but does not include any prefix information in it
>    (implicit mode), this field is set to null.
> 
> JARI: So, if you run a routing protocol over the tunnel, will this
>       information be updated in the BUL as well?

I think its not needed when a routing protocol is being run.

>    If the Binding Acknowlegement status is set to '0' (Binding Update
> 
> JARI: I don't understand this vs. what you are saying above in Section
>       5.3. What is the issue? Is it perhaps that due to your rules,
>       you can do an R registration without a single moboption and
>       hence the HA does not recognize that it doesn't support R? If
>       so, you should require your moboptions to be always present...
> 
>    accepted), the Mobile Router concludes that the Home Agent which
>    processed the Binding Update is a MIPv6 Home Agent that has not
>    implemented support for Mobile Routers.  It should send a similar
>    Binding Update to another Home Agent on the link.  If no Home Agent
>    replies positively then the Mobile Router MUST refrain from sending
>    any Binding Update with the Mobile Router flag set to any home agent
>    on the home link and log the information.
> 
> JARI: Hmm... forever?

actually this whole paragraph needs to be removed. it is left over
text from previous edits. my mistake.

>    A Mobile Router MAY limit the number of mobile routers that attach to
>    its mobile network (the number of levels in the nested aggregation)
>    by means of setting the Tunnel Encapsulation Limit field of the
>    Tunnel Encapsulation option.
> 
> JARI: So what happens if there is a loop? A packet that you send
>       travels through the loop until the encapsulation limit
>       is reached? Or is there some other defense?
> 

I guess this is related to your issue on loop detection. I will add
this to issue 24.

>    A Mobile Router MUST NOT ignore Router Advertisements received on
>    the egress interface.  The received Router Advertisements MAY be
>    used for address configuration, default router selection or movement
>    detection.
> 
> JARI: I wonder if the above paragraph could be replaced with
>       some reference to ND specs. As far as I can see, an MR should
>       follow ND rules on its egress interface when on a visited
>       network. 
> 

if you go by ND specs, routers ignore router advertisements. we are
infact saying router advertisements MUST NOT be ignored.

>    In some deployment scenarios it may be necessary for the Home Agent
>    to prevent a misbehaving Mobile Router from claiming mobile network
>    prefixes belonging to another Mobile Router.  The Home Agent can
>    prevent such attacks if it maintains a Prefix Table and verifies the
>    Prefix Information provided by the Mobile Router against the entries
>    in the Prefix Table.  However, this verification is done only if the
>    Binding Update contained explicit prefix information in the form of
>    either the Mobile Network Prefix Option or the Mobile Network Prefix
>    Length Option.
> 
> JARI: I think that verification could also be done at the routing
>       protocol case, assuming the HA can link the virtual interface
>       and the corresponding MR together.
> 

we assume routing protocols have their own mechanism for verifying
the routing information sent by a router. so we did not recommend
anything in the routing protocol case.

>     -  The Home Registration (H) flag MUST be set.  If not, the
> 
> JARI: Use 'H' instead of (H)

MIPv6 spec uses (H). :)

> JARI: Is it possible to go from a "R=1" BCE to an "R=0" BCE in
>       some manner? Or only deleting the BCE and registering
>       again?

the mobile router has to de-register and then register again.

>    The establishment and operation of the bi-directional tunnel is
>    implementation specific.  However, all implementations MUST be
>    capable of the following operations.
> 
> JARI: What does it mean that its implementation specific? What
>       specifically would you have to do to establish the tunnel
>       in the first place? Why can't this be specified?

setting up and using tunnels is implementation specific. some
people like to set them up as virtual interfaces. sometimes it
is just code in the IP stack.

> The Home Agent either uses only the routing
>    table, only the Binding Cache or a combination of routing table
>    and Binding Cache to route packets to the mobile network.  This is
>    implementation specific.  Two examples are shown below.
> 
> JARI: You are presenting the rules in a too implementation-near
>       form. Perhaps you could formulate something general
>       that has a MUST.
> 

there is a problem with it. the binding cache is a conceptual
data structure. sometimes it is just implemented as a routing
table entry. one implementation (of mobile routers), I know,
uses the binding cache for both routing and CoA lookup. so
we left it implementation specific. and we present two ways
of doing it.

we had a long discussion on using the binding cache or routing
table for the HA to forward packets to the mobile network. this
discussion happened before this draft was written up.

>    In the solution described so far, forwarding to the Mobile Network
>    at the Home Agent is set up when the Home Agent receives a Binding
>    Update from the Mobile Router.  An alternative to this is for the
>    Home Agent and the Mobile Router to run an intra-domain routing
>    protocol like RIPng [10] and OSPF [11] through the bi-directional
>    tunnel.  The Mobile Router can continue running the same routing
>    protocol that it was running when it was attached to the home link.
> 
>    This feature is very useful when the Mobile Network is large with
>    multiple subnets containing different IPv6 prefixes.  Routing changes
> 
> JARI: Can you give a practical example of where this could be the
>       case? I can't think of any, but maybe its just me...

it could happen when there are multiple mobile networks attached
to the mobile router, each one having different prefix, but want
routing enabled for all these prefixes through the Home Agent.
using a routing protocol makes sense here.

>    Since the routing protocol messages from the Home Agent to the Mobile
>    Router could potentically contain information about the internal
>    routing structure of the home network, these messages require
>    authentications and confidentiality protection.  Confidentialy
>    protection using IPsec ESP [4] in tunnel mode MUST be supported and
>    SHOULD be used.
> 
> 
> JARI: It might be necessary to have some more detail about this.
>       What kind of SPD entries are needed etc.

should be straight forward. OSPFv3 and RIPng use specific transport
protocols and ports. for example the SPD entry on the mobile router
would say "if routing protocol message with destination=HA, use a
particular SA which would do tunnel mode ESP".

your other suggestions were accepted.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Tue, 02 Dec 2003 11:25:15 +0200

Thanks Vijay for your prompt answer. I'm happy
with most of your answers, some further discussion

>    inside the mobile network.

Ok.

> terminology that is being advanced as an informational RFC. so

I think that other document would have value even if you
copied some of the terms (used ones) to the basic nemo
document.

Anyway, I don't think it is crucial. Just a practical issue
that I noticed when reading.

> this. so we left it optional. I dont mind making it mandatory.

That would make sense. Imho all nemo-based products
should support this function.

> mobile networks are not transit networks. always stub networks.

I'm still having some difficulty with the transit network
part. I looked up one definition of a transit network from RFC
1584, which talks about the number of attached routers. However,
in the nested nemo case you could actually have several attached
routers, hidden inside tunnels. And would you allow multiple
MRs per Mobile Network or not? I think not, because then you
would appear like a transit network, according to the
RFC 1584 definition. OTOH, I'm not sure why such a limitation
would be necessary in the technical sense.

Is it allowed for an MR to have two home agents, home addresses,
and network prefixes? Is there any case where the Mobile Network
would become a transit network in such a situation?

How about this:

    A Mobile Network is a network segment or subnet which can move
    and attach to arbitrary points in the Internet.  A Mobile Network
    can only be accessed via specific gateways called Mobile Routers
    that manage its movement. Mobile Networks have (always exactly)|
    (at least) one Mobile Router serving them.

> have the same prefix as the MR.

Ok.

> carrying prefix information in the Binding Update.

If this is the case, perhaps you could remove the static alternative
then? My concern is mainly the number of alternatives. I'd rather
have less alternatives, even if the BUs would carry a few more bytes
in some cases...

> :) only if the mobile router has configured all its home addresses

Yeah. But to support S=0 all I have to do is to agree about
suitable prefixes with my home agent, and set R=1...

I'm not really suggesting you change anything, just making
an observation.

But doesn't this point to an additional reason for making
the Prefix Table functionality mandatory? How else would
the HA know which prefixes to give to the MR, if no prefixes
were mentioned in the BU?

> why? are we missing something.

Would it be useful to follow MIPv6 base Section 5.5 guidelines
on the use of source addresses?

> entries even though the mobile router is currently dormant or just

Its additional state yes, but packets destined to the prefix will
be dropped on the floor in any case.

> which one are you referring to?

Either one.

> I think its not needed when a routing protocol is being run.

Ok. Perhaps you could explicitly say this.

> text from previous edits. my mistake.

Ok.

> I guess this is related to your issue on loop detection. I will add

Ok.

> infact saying router advertisements MUST NOT be ignored.

I guess this is related to the MR turning to a host, as far
as any external observer can determine, when it attaches to
a foreign network.

> anything in the routing protocol case.

Ok. Maybe an explicit note about this too is needed.

>> JARI: Use 'H' instead of (H)

Well, what I really meant was to use one form all over the
place ;-)

> the mobile router has to de-register and then register again.

Ok.

> is just code in the IP stack.

Perhaps you could change the text to avoid a perception
that the protocols are not fully defined. How about this:

     The implementation of the bi-directional tunnels and the mechanism
     of attaching them to the IP stack are outside the scope of this
     specification. However, all implementations MUST be capable of
     the following operations.

> discussion happened before this draft was written up.

Ok.

(Perhaps you could change the first paragraph of 6.5 to
have a keyword. This would be the normative part, the rest
is implementation guidance.)

> using a routing protocol makes sense here.

I think the key question here is whether running the routing
protocol makes a difference in the end. Is it used to avoid
sending useless packets to the MR? Most likely such traffic
would be minimal, given that there would be no response from
the networks that are currently disconnected. Or is it used
to make some real routing changes, such as switching the
traffic from one HA site to another one? If yes, this needs
to be supported.

Like I said above, I'm primarily concerned about the number
of alternatives and that's why I'm trying to see if we really
have a true need for all three, i.e. static, BU, and routing
protocol alternatives.

> particular SA which would do tunnel mode ESP".

How about writing this down somewhere in the document? As you
know, "should be straight forward" is not always a guarantee
that things will actually be like that ;-)

> your other suggestions were accepted.

Thanks.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 02 Dec 2003 11:25:15 +0200

Ok.

How about this:

Ok.

Either one.

Ok.

Ok.

Ok.

Ok.

Thanks.

--Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 12:02:57 -0800

> that I noticed when reading.

I am okay with copying some of the terms from the terminology
document so that the basic support spec is self contained. if
nobody has any objection I will go ahead and do this.

> That would make sense. 

you mean making it mandatory makes sense? maybe a SHOULD, not a
MUST.

> Imho all nemo-based products

I agree too.

>    (at least) one Mobile Router serving them.

fine with me.

> have less alternatives, even if the BUs would carry a few more bytes

I would rather remove the explicit prefix length mode. the implicit
mode I think is needed for minimal implementations of mobile routers.
they are also needed when routes are managed by manual configuartion
at the Home Agent, i.e. the routes are always there on the Home Agent
and are just modified to reflect the current point of attachment of
the mobile router.

> were mentioned in the BU?

how about manually configured routes which always exist on
the Home Agent. we should keep it open. it is internal to
the Home Agent.

> on the use of source addresses?

we already say in the spec (section 5.5), what the source and
destination addresses should be for the inner and outer IPv6
headers when sending packets through the bi-directional tunnel.

> Ok. Perhaps you could explicitly say this.

okay.

> as any external observer can determine, when it attaches to

right. implementors need to explicitly enable the mobile routers
to process router advertisements received on its egress interface.

>     the following operations.

okay.

> is implementation guidance.)

I am not sure I got. is this what you are getting at?

    When the Home Agent receives a data packet destined for the mobile
    network, it MUST forward the packet to the Mobile Router through the
    bi-directional tunnel.  The Home Agent either uses only the routing
    table, only the Binding Cache or a combination of routing table
    and Binding Cache to route packets to the mobile network.  This is
    implementation specific.  Two examples are shown below.

> traffic from one HA site to another one? If yes, this needs

what I would like to see is something we called a fully enabled
case in another draft. the mobile router runs a routing protocol
with its Home Agent to manage all routes. the mobile router also
gets to know about the routes on the home domain through its
Home Agent. the use of binding updates to do this is a poor
substitute, IMO.

> have a true need for all three, i.e. static, BU, and routing

I would like to enable the basic NEMO spec to be able to use
a dynamic routing protocol.

> that things will actually be like that ;-)

hmm.. I will try to come up with some text in the Security
Considerations section.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 12:02:57 -0800

I agree too.

fine with me.

okay.

okay.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Tue, 02 Dec 2003 22:46:12 +0200

> nobody has any objection I will go ahead and do this.

Great!

> you mean making it mandatory makes sense? maybe a SHOULD, not a

SHOULD is ok.

>>    (at least) one Mobile Router serving them.

Ok, but you still need to pick either "always exactly" or
"at least".

> headers when sending packets through the bi-directional tunnel.

Yes, but you are not requiring that the source addresses be
checked. This opens a reflection attack via home agents that
don't get this.

I think you need to add that, either as your own text or
via reference.

>    implementation specific.  Two examples are shown below.

Exactly like that, thanks.

Ok.

> hmm.. I will try to come up with some text in the Security

Good.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Tue, 02 Dec 2003 22:46:12 +0200

Great!

SHOULD is ok.

Ok.

Good.

--Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 13:06:20 -0800

> Ok, but you still need to pick either "always exactly" or

we cannot restrict to one mobile router. so its "at least".

> checked. This opens a reflection attack via home agents that

there is some text in the Security Considerations section.

    The Home Agent has to verify that packets received through the
    bi-directional tunnel belong to the Mobile Network.  This check is
    necessary in order to prevent nodes from using the Home Agent to
    launch attacks that would have otherwise been prevented by ingress
    filtering.  The source address of the outer IPv6 header MUST be set
    to the Mobile Router's current Care-of address.  The source address
    of the inner IPv6 header MUST belong to the Mobile Network Prefix
    owned by the Mobile Router.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 13:06:20 -0800

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Dec 2003 00:08:53 +0200

>    owned by the Mobile Router.

Ok, thanks -- I missed it initially.

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Dec 2003 00:08:53 +0200

--Jari

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 02 Dec 2003 17:05:03 -0800

>> copied some of the terms (used ones) to the basic nemo
Can you explain what the point is of having a separate NEMO terminology 
document if the basic support spec is self-defining? It seems that we 
followed the general trend in IETF WGs to have a more general 
terminology document, and then use those terms in the protocol 
specification. Can you point to a reference or suggestion by the IESG or 
ADs have suggested that everything be self-referential? I would 
personally like to know what the BCP on this is at the moment, since it 
seems like pushing the terms back in to make a larger document is like 
swimming upstream.

>> that I noticed when reading. 
Not crucial, but we would like to make sure that things end up in a best 
useable form.

>>> this. so we left it optional. I dont mind making it mandatory.

A table of owned prefixes is only one possible way for the Home Agent to 
determine which prefixes an authenticated MR is authorized to use NEMO 
with. That's why it's optional.

>> should support this function.

Of a prefix table? Yes, in statically configured cases, which is 
probably the most useable in the near term, we would highly recommend 
using this static mapping. But someone could always hook up a database 
and do lookups, when the list is managed by another piece of software.

>> would be necessary in the technical sense.

True, traffic inside a mobile network can transit from one sub-network 
to another sub-network. However, consider this rule, which might help 
clarify:

(a) For all mobile networks, there is a defined boundary in which all 
nodes are considered part of the mobile network, and then we say that 
all packets entering the mobile network (through one or more top-level 
mobile routers) MUST be destined for addresses within the mobile 
network, that means it is NOT a transit network, since no packets will 
enter the mobile network at one point, be forwarded, and leave the 
mobile network at another (or the same) point.

(b) When you have nested MRs inside mobile network (a), then we just 
apply the above definition in a recursive manner: the mobile network 
served by one of the nested mobile routers becomes the mobile network in 
definition (a), then you just apply the same definition and it still 
holds true.

>>
>> Is it allowed for an MR to have two home agents,
>
Inasmuch as a MN can have two home agents.

>> home addresses, 
ditto.

>> and network prefixes?
In the mobile network? definitely.

>> Is there any case where the Mobile Network
Yes, here are a couple examples:

How about the case where an MR is authorized to use the set of prefixes 
P1, and it only wants to use a subset of those prefixes, set P2 (c P1). 
It does not want the subtraction P1 \ P2 prefixes forwarded.

Next, consider a case where a bunch of MRs share a pool of prefixes. A 
prefix is dynamically assigned to the mobile network as soon as the MR 
authenticates to the HA. At that time, the HA picks a prefix and uses 
the option to explicitly tell the MR its prefix.

> the Home Agent. we should keep it open. it is internal to

Yes, I can see both of your points, since this is a "basic" support 
draft. Let's hear what others in the WG think about this, since it may 
be better to sacrifice flexibility for simplicity.

> to process router advertisements received on its egress interface.

Yes, this is a good point which we have mentioned many times, but 
perhaps can be clarified more in the spec. To the entire Internet except 
the HA, the MR looks like a MN (host). To the entire mobile network, the 
MR looks like a fixed router. To the HA, the MR looks like an MN with 
some added bells and whistles.

No other comments, but thanks for yours.

TJ

---

From: "T.J. Kniveton" <[email-masked]>
Date: Tue, 02 Dec 2003 17:05:03 -0800

ditto.

TJ

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 17:32:41 -0800

T.J. Kniveton wrote:
> document if the basic support spec is self-defining? 

well, I see the terminology document being absolutely essential for
any meaningful discussion on the mailing list. before the terminology
document was written, most of the time everybody was trying to figure
what the other person was referring to.

I agree with Jari that the basic support draft should be self-contained
when it comes to terminology.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 02 Dec 2003 17:32:41 -0800

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Dec 2003 10:22:09 +0200

> with. That's why it's optional.

Ah, I see. I don't think that you should require a table. You
should require an ability to tell which prefixes are legal for
a given MR. Folks can then implement this as a table, an AAA
lookup, a database, or whatever they want.

Ok.

> the option to explicitly tell the MR its prefix.

Right. And this would be a useful function. But I guess
it would have to be written down somewhere? Currently you
say your options are only used in the BU. What you suggest
above belongs to a new "dynamic MR prefix assignment"
spec, probably...

--Jari

---

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Dec 2003 10:22:09 +0200

Ok.

--Jari