Subject: [nemo] Comments on basic support

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Oct 2004 18:15:17 -0700

Comments on draft-ietf-nemo-basic-support-03.txt

Overall the draft is quite good.

Some comments and questions below:

1. Section 3 is doesn't talk about authorization for a MR routing a specific
prefix. I suggest adding text after
    Update.  The Home Agent sets up forwarding for each of these prefixes
    to the Mobile Router's Care-of Address.
saying:
    , once it has verified that the mobile router is authorized to route to
    those prefixes.  The mobile IPv6 mechanisms [1] provides for 
authentication
    and the authorization might be performed by maintaining a list of the
    prefixes which each MR (i.e., Home Address) is allowed to route.

Note that this is merely an example. Another example would be that the 
class of
MRs (identified by e.g. the CA+certificate name string in the cert used to
setup IPsec) are associated with a set of allowed prefixes.
I don't know if folks want to add a new section with multiple examples of
how authorization checks can be performed.  If not, the above example should
at least point out to implementors that some checks are required.

2. Section 1 says
    The Home Agent acknowledges the Binding Update by sending a Binding
    Acknowledgment to the Mobile Router.  A positive acknowledgment
    means that the Home Agent has set up forwarding for the mobile
    network.
I suggest clarifying the second sentence to say
    A positive acknowledgment with the R bit set
    means that the Home Agent has set up forwarding for the mobile
    network.

3. Section 4.2 has
       140     Mobile Router Operation not permitted

       141     Invalid Prefix

       142     Not Authorized for Prefix

       143     Forwarding Setup failed
I understood the meaning of all but 143. From the text it looks like
the meaning is "Prefix missing"/"Can't do implicit mode"
so why not name the error something along those lines?

4. Multiple prefixes and errors
I don't know exactly where it makes sense to clarify this,
but the document should say that if one prefix can't be setup,
the the HA will not setup any of them.
Perhaps saying "if any prefix fails, then all of them will fail" in
section 4.3?
Also, adding this to the 5th paragraph in section 6.6?

5.Section 5.4.1 and 5.4.2 has these sentences with
    The Mobile Router MUST discard Binding
    Acknowledgments with status ...
I can understand that the error codes don't make sense in the specific case,
but silently ignoring them seems wrong; after all a binding ack with such
an error indicates that the HA didn't set things up, and pretending that the
BA wasn't received by discarding it isn't useful.
Thus I think you want to say something like
    Since Binding Acknowledgments with status ... should not happen in
    implicit mode, the Mobile Router will treat them as fatal errors
    (just like most >=128 are fatal errors).

6. Section 5.5 suggests using the Tunnel Encapsulation Limit,
but I don't think it has the suggested effect.
A MR can use the option to limit how much nesting occurs "above" the router
i.e. between the MR and the Internet, but can't use it to limit how
much nesting is "below" it i.e. how deep chains of nested MRs attach to
the MR, which is what the text suggests.
Or am I the one who is confused?

The MR could limit the amount of nesting "below" it by parsing the packet
to see how many IP headers are present, but this fails if ESP tunnels are
used.

7. Section 5.6 says
    when that interface is attached to a visited link.  However, the
    Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor
    Solicitations received on the egress interface, for topologically
    correct addresses.
and I have no idea what "topologically correct" means in this context.
Shouldn't the MR just reply for the addresses it has assigned to the egress
interface, just like any other node?

Or is this trying to hint at some form of proxy ND?

8. When multiple prefixes are included, then the status in the
binding ack signaling an unauthorized prefix doesn't help tell the MR
which is the bad prefix.
Is this something that has been discussed?
If one wanted to provide this information, one could make the Binding Ack
carry prefix options, either for all the failed or for all the acceptable
prefixes.

9. Section 6.2 has a suboptimal order.
After the discussion of the prefix checks, it has the paragraph for
unregistering. Since the unregistering check ignores the prefixes
it would be clearer if that paragraph was placed earlier in section 6.2.

10. I don't understand how the R bit in the DHAD request and replies help.
First of all, when all the HAs on the home link are upgraded to support MRs,
which is likely to be the common case, it isn't needed.
When some HAs support it and others do not, then in some cases the
anycast DHAD request will reach an HA which doesn't understand the R bit.
Hence the MR needs to be prepared to handle the reply without the R bit,
by trying all the listed HAs. Hence the R bit is an optimization for this
"not all support it" case when the anycast happens by chance to reach a
HA which supports MRs. It doesn't seem worth while to add the R bit
to optimize this infrequent case.

11. Section 9 says
    In case the Mobile
    Router receives a IP-in-IP tunneled packet from a node in the Mobile
    Network and the Mobile Router has to forward the decapsulated packet,
    it SHOULD perform the above mentioned checks on the source address of
    the inner packet.
In don't understand why this restriction is in place.
Wouldn't it prevent nested mobile networks where the "lower" one will use
its home address, which the upper MR has no knowledge of, in the inner 
header?

12. Section 9 should say something about authorization checks before the MR
can cause routes to be injected by the HA, whether this is done using prefix
options or running a routing protocol.

13. Appendix B.2 says:
    The following should be considered when the Home Network is
    configured for running OSPF.

     -  The entire Home domain SHOULD NOT be configured as a single area
        if a Home Agent supports Mobile Routers.  At least the Home
        Network should be configured as a separate area.

     -  The bi-directional tunnel interfaces to the Mobile Routers should
        never be included in the same area as the backbone links.

I don't understand the motivation for this? Is it performance related?
If I run a flat (no areas defined) OSPF routing domain
with 4 links and 4 prefixes, the above "SHOULD" appears to force me to
configure areas. At a minimum the text should explain the basis for
the considerations, and perhaps also say that they apply to large routing
domains.

14. Since the IETF has been notified of IPR, I think that form of
"Intellectual property statement" should be used.

15. It makes sense to run a spell checker. I found the spelling
"infrasructure".

     Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Oct 2004 18:39:49 +0200

>    prefixes which each MR (i.e., Home Address) is allowed to route.

I agree with this text.

> at least point out to implementors that some checks are required.

I do not want to add such a new section; other draft may be ok.

>    means that the Home Agent has set up forwarding for the mobile

I agree with this modification, it is more precise (Vijay: it's section
3 not 1).

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Oct 2004 19:01:03 +0200

> so why not name the error something along those lines?

Another meaning we've discussed was that 143 could be sent by HA when
its routing table was full. Here 130 Insufficient resources could be
used though (but with or without the R bit?). Or if an existing route
existed already (towards a different Gateway).

Otherwise I agree with the naming, it's good to be explicit about
implicit mode's error codes.

> Also, adding this to the 5th paragraph in section 6.6?

Do we want the behaviour that "if any prefix fails then all of them will
fail" or do we want the behaviour "set as many prefixes as you can, please".

>    (just like most >=128 are fatal errors).

Ok, it makes sense. Instead of discarding, just treat as other BAck 
fatal errors (128-139). I'm not sure how RFC3775 reuires this to be.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Oct 2004 19:12:59 +0200

Erik Nordmark wrote:
> 6. Section 5.5 suggests using the Tunnel Encapsulation Limit, but I
> don't think it has the suggested effect. A MR can use the option to
> limit how much nesting occurs "above" the router i.e. between the MR
> and the Internet, but can't use it to limit how much nesting is
> "below" it i.e. how deep chains of nested MRs attach to the MR, which
> is what the text suggests.

I guess this is right.  I think the current text is wrong.  MR adding a
DO with the Enc Limit option EL has the effect the MR's above it will
further encapsulate (or not) this originating packet; a certain MR
adding a DO EL has no effect on limiting the number of nested MR's below it.

That single paragraph (A Mobile Router MAY limit...) can be removed.

A certain MR may limit how much nesting occurs above it.  If this needs
to be explicitely stated or not - I'd say no.

> The MR could limit the amount of nesting "below" it by parsing the
> packet to see how many IP headers are present, but this fails if ESP
> tunnels are used.

Yep.  I don't think it needs to be said here at all.

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Oct 2004 19:27:12 +0200

> interface, just like any other node?

It's never been clear to me by RFC3775.  But I'm sure MR must not reply 
for the Home Address if MR not on the home link, hence "topologically 
correct".  Maybe removing "topologically correct".

> Or is this trying to hint at some form of proxy ND?

No.

Proxy ND of what to what?

> carry prefix options, either for all the failed or for all the acceptable

This has not been discussed, IIRC.  It occured to me once, but did not 
want to complicate things.  This is all in Error Processing.  This must 
be as simple as possible.  I was lazy.  If more people think we should 
include this feature, ok.  Including prefixes maybe it's too long, maybe 
indexing them and exchange indexes to point the errors.

> to optimize this infrequent case.

It boils down to deciding whether upgrading all-at-once is more probable
than just adding a new HA that supports MR's. I do not know. I
personally think test deployments will happen where NEMO-enabled HA's
and non-NEMO-enabled HA's exist on the same link, but that's just me maybe.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 22 Oct 2004 15:11:34 -0700

> existed already (towards a different Gateway).

If you use 143 for this, then it would have the effect that the MR migh 
try again while specifying prefix option(s), which wouldn't be useful.
So I don't think you want to do that.

> fail" or do we want the behaviour "set as many prefixes as you can, 

I think we should pick one choice and make that work.
Receiving an error (>=128) would presumably imply that no state change 
occured on the HA.
So if we want "as many as you can", I think there should be
  - a status < 128
  - an indication (by including the prefix options in the ack?) which
    ones failed

But I think it is simpler to make it an atomic all or nothing.
Perhaps the binding ack should indicate which one(s) were bad to make it
easier to debug this during interoperability testing etc.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 22 Oct 2004 15:19:05 -0700

> correct".  Maybe removing "topologically correct".

I'd suggest replacing it with "the CoA" or "the addresses assigned to 
the egress interface".

I don't think there is any harm in responding for the HoA while away 
from home, since nobody should be sending NSs for it.
And RFC 3775 leaves that open. So some implementations might, and others 
might not because they have assigned the HoA to some tunnel interface 
when they moved away from home.

> indexing them and exchange indexes to point the errors.

I think it might be a benefit in debugging during interop testing, but I 
don't think it would be useful in operational settings.

> and non-NEMO-enabled HA's exist on the same link, but that's just me maybe.

I don't have a problem with incremental upgrade of HAs. It is just that 
the R bit isn't very useful since the MR must be prepared to try all the 
HAs when it gets a DHAD reply with no R-bit. So why not have it do this 
all the time?

You are optimizing for the case when the DHAD request reaches an 
upgraded HA, and IMHO this is not worth optimizing for.

    Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 22 Oct 2004 15:45:51 -0700

hi Erik,

thanks for the review.

>    prefixes which each MR (i.e., Home Address) is allowed to route.

we do talk about it in section 6.1.2.

for section 3, how about just the following

      The Home Agent sets up forwarding for each of these prefixes to the
      Mobile Router's Care-of Address, once it has verified that the
      mobile router is authorized to route to those prefixes.

>    means that the Home Agent has set up forwarding for the mobile

okay.

> so why not name the error something along those lines?

I am fine with the change, but this might mean sending the document
back to IANA. IANA has already done the assignments.
http://www.iana.org/assignments/mobility-parameters. and they call it
"Forwarding Setup failed". maybe we can avoid this change. (?)

> Also, adding this to the 5th paragraph in section 6.6?

we have some text in section 6.2

     -  If a Mobile Network Prefix Option is present in the Binding
        Update, the prefix information for the Mobile Network Prefix is
        retrieved from the Mobile Network Prefix field and the Prefix
        Length field of the option.  If the Binding Update contains more
        than one option, the Home Agent MUST set up forwarding for all of
        the Mobile Network Prefixes.  If the Home Agent fails to setup
        forwarding to all the prefixes listed in the Binding Update, then
        it MUST NOT forward traffic to any of the prefixes, reject the
        Binding Update and send a Binding Acknowledgement with status set
        to 141 (Invalid Prefix).

dont you think this is enough?

>    (just like most >=128 are fatal errors).

this is fine with me. proposed text

section 5.4.1

    In Implicit mode, the Mobile Router interprets only error status
    '140' (Mobile Router Operation not permitted) and '143' (Forwarding
    Setup failed).  The Mobile Router MUST treat Binding Acknowledgements
    with status '141' and '142' as fatal errors, since they should not be
    sent by the Home Agent in implicit mode.

section 5.4.2

    If the Mobile Router sent a Binding Update to Home Agent in explicit
    mode then the Mobile Router interprets only error status '140'
    (Mobile Router Operation not permitted), '141' (Invalid Prefix) and
    '142' (Not Authorized for Prefix).  The Mobile Router MUST treat
    Binding Acknowledgements with status '143' as a fatal error, since it
    should not sent by the Home Agent in explicit mode.

> Or am I the one who is confused?

this is embarassing. we should have caught this before. you are right,
Eric. this will not help the MR in limiting the number of nested levels.
maybe we need to delete the entire paragraph.

> interface, just like any other node?

well, this was put for the MR to avoid replying to any addresses that
make no sense on the visited link. for example if the MR has a HoA and
CoA configured on the egress interface, we want the MR to respond to
neighbor solicitations only for the CoA and not for the HoA.

> carry prefix options, either for all the failed or for all the acceptable

I will send a separate mail on this.

> it would be clearer if that paragraph was placed earlier in section 6.2.

you are right. fixed this.

> to optimize this infrequent case.

have you already looked at the discussion in issues #15 and #16?
http://people.nokia.net/vijayd/nemo/issues.html.

if the MR gets a reply from a Home Agent with the R bit set, it doesnt
have to try anymore HAs.

> its home address, which the upper MR has no knowledge of, in the inner 

please see issue 23. http://people.nokia.net/vijayd/nemo/issue23.txt.
it should be possible for the "lower" MR to send a packet you want
by setting the destination address on the outer IP header to its own
HA, instead of the "upper" MR.

> options or running a routing protocol.

if the MR and the HA are running a routing protocol, Alex Zinin didnt
want any text about authorization checks. he said, the routing protocols
take care of it. for example, if all the routers in a domain are using
a shared key to authenticate routing protocol messages, the fact that
the shared key was used should be enough to authorize the routing
messages. he didnt want separate checks specified by NEMO.

there was a long discussion captured in Issue 31.

I guess we need to add the following sentence to the security
considerations section.

    If the Mobile Router sends a Binding Update with a one or more
    multiple Mobile Network Prefix options, the Home Agent MUST be able
    to verify that the Mobile Router is authorized for the prefixes
    before setting up forwarding for the prefixes.

> I don't understand the motivation for this? Is it performance related?

yes. see issue 31 again.

otherwise, if there is a change in routing in one Mobile Network, the
entire Home Domain would get to know about it. if there is a change
in routing in the home domain, all the mobile routers get a link state
message.

> the considerations, and perhaps also say that they apply to large routing

I can add some text to justify the two bullet points.

    The above is necessary to restrict the routing protocol messages to
    the Home Network, instead of sending the messages to the entire Home
    domain.

> "Intellectual property statement" should be used.

I am a bit ignorant here. is it missing the following text?

    The IETF has been notified of intellectual property rights claimed in
    regard to some or all of the specification contained in this
    document. For more information consult the online list of claimed
    rights.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 22 Oct 2004 16:48:16 -0700

> HAs when it gets a DHAD reply with no R-bit. So why not have it do this 

without the 'R' bit in the DHAAD reply, a MR does not know that the
HA does not support Mobile Routers, until it sends a Binding Update
and gets a Binding Ack without the 'R' bit. it would be a good idea
for the MR to know this a bit earlier. :)

Vijay

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 24 Oct 2004 21:48:06 -0700

> we do talk about it in section 6.1.2.

Yes, but in the interest of gradual disclosure as you read the document,
I think it should be mentioned in section 3 as well.

And, FWIW, section 6.1.2 doesn't have the word "authorized" which I 
think is the key concept to make clear to the reader here.

>      mobile router is authorized to route to those prefixes.

Given that subsequent sections are a bit poor at using "authorized"
I think it would be hard for the reader to connect the dots.
If we could use "authorized", or have forward references to the relevant 
sections, then this would be ok.

> "Forwarding Setup failed". maybe we can avoid this change. (?)

I don't know what the overhead would be; the IANA needs to edit the 
registry anyhow to enter the RFC number so perhaps they can change the 
name at the same time. The registry currently says
   143 Forwarding Setup failed     [draft-ietf-nemo-basic-support-03.txt]

If it is hard to get that edit to the IANA, how about making the I-D/RFC 
add a parenthesis e.g.
	143 Forwarding Setup Failed (prefixes missing)

> dont you think this is enough?

I did see that text, but is it less than clear.
It doesn't say "do not add the prefix to the list" but instead it says 
"do not forward traffic". So perhaps the reader will think it should be 
added to the list but not used? And this is the only place where it 
talks about the behavior under failure.
So changing the above to say "do not add to the list" would be an 
improvement, but it would also make sense to state the "all or nothing" 
aspect of the list of prefixes earlier in the document - perhaps where 
the prefix option is defined.

>    should not sent by the Home Agent in explicit mode.

ok

> neighbor solicitations only for the CoA and not for the HoA.

The text doesn't say that.
If you want to say "SHOULD respond for the CoA and MAY respond for the 
HoA" you should be explicit about it.
(I'm assuming you don't want to prohibit implementations from responding 
for the HoA, since it would be harmless.)

> http://people.nokia.net/vijayd/nemo/issues.html.

Those issues are about BU/BAck - my comment was about DHAD request and 
reply.

> if the MR gets a reply from a Home Agent with the R bit set, it doesnt

And what does this have to do with DHAD?

My point is that the R-bit in DHAD request/reply doesn't seem to be of 
my use, since the MR needs to be prepared to try all the listed HAs when 
the R bit is not set in the reply.
It is worth complicating the protocol by adding the R-bit with DHAD when
the MR still needs to have code to try all HAs? I don't think so.
But if this has been discussed already, I'll go read the discussion.

> HA, instead of the "upper" MR.

But the text in the draft doesn't say that this check only applies to 
packets addressed to one of the MRs address; I read it as applying to 
all IP-in-IP packets that the MR forwards.
So I suspect some clarification would be helpful.

> messages. he didnt want separate checks specified by NEMO.

ok.

>    before setting up forwarding for the prefixes.

Apart from the extra "multiple" above, it looks ok.

>> I don't understand the motivation for this? Is it performance related?

Sorry, the RFC needs to capture and explain an issue like this.

> I can add some text to justify the two bullet points.

Thanks.

>    the Home Network, instead of sending the messages to the entire Home

With with my 4 link OSPF routing domain that would be perfectly 
acceptable. So the note needs to be about the increased load especially 
for large IGP domains.
(And I think IS-IS and RIPv2 has the same issue as OSPF here.)

>    document. For more information consult the online list of claimed

That's the gist of it (I didn't check the above text against the 
boilerplate).

     Erik

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 24 Oct 2004 21:51:25 -0700

> for the MR to know this a bit earlier. :)

So the semantics are two-fold:
  - the router sending the DHAD reply supports MRs
  - all the listed HAs support MRs?

That wasn't obvious from reading the draft.

    Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 25 Oct 2004 11:06:05 +0200

Erik Nordmark wrote:
>> It's never been clear to me by RFC3775.  But I'm sure MR must not 
>> reply for the Home Address if MR not on the home link, hence 
>> "topologically correct".  Maybe removing "topologically correct".
> 

A host sending periodic NA's for the Home Address while away from home
has the effect that its neighbours on the visited link fill their cache
with this address.  Further effect is that when such a neighbour writes
to the Home Address the communication doesn't go to MR's HA, but
directly to the MR.

Anyways, if we let MR send NA's for HoA on the visited link these should
at least have R-bit unset (while at home it should be set).

> And RFC 3775 leaves that open. So some implementations might, and 
> others might not because they have assigned the HoA to some tunnel 
> interface when they moved away from home.

I see this.

>> This has not been discussed, IIRC.  It occured to me once, but did 
>> not want to complicate things.  This is all in Error Processing. 
>> This must be as simple as possible.  I was lazy.  If more people 
>> think we should include this feature, ok.  Including prefixes maybe
>>  it's too long, maybe indexing them and exchange indexes to point 
>> the errors.
> 
> I think it might be a benefit in debugging during interop testing, 
> but I don't think it would be useful in operational settings.

So do you mean (1) we should enhance the BAck to put prefixes in it, or
(2) should we enhance the BU first with prefix indexing and then put
indexes in the BAck?  I think the latter method saves on bandwidth but
the former method maybe it is more helpful to have prefixes visible in
packet dumpers.

Should this be in a Binding Error instead.

The prefix-BAck is supposedly used only in Explicit mode.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 25 Oct 2004 09:17:05 -0700

> at least have R-bit unset (while at home it should be set).

Are we changing the subject?
The previous subject was responding to Neighbor Solicitations for the 
HoA while away from home, which I argue is harmless.

On the subject of periodic unsolicited NAs for the HoA (which is NOT 
what the text in the draft is about) I think periodic unsolicited NAs is 
a bad idea in general (but they are not explicitly prohibited in RFC 
2461 I think), and it would be bad to do those for a HoA while away from 
home as you point out.

> the former method maybe it is more helpful to have prefixes visible in

*If* you want to add this, putting the prefix options that failed in the 
BAck would be the easiest and it doesn't make any packet any larger when
things are working (since it that case all prefixes were ok).

> Should this be in a Binding Error instead.

I don't think so, since that is today only sent in response to data 
packets and not in response to Binding Updates.

    Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 25 Oct 2004 19:21:06 +0200

Erik Nordmark wrote:
> Are we changing the subject? The previous subject was responding to 
> Neighbor Solicitations for the HoA while away from home, which I 
> argue is harmless.

No, I'm not changing subject, I stay within the section of how MR acts
ND-wise.  I see your point, capacity of responding to NS's for the HoA
is harmless in the visited network simply because there are no such
NS's.  So yes, I agree the current text "for topologically correct
addresses" appears superfluous.

So I think it is still good to forbid MR to send NA's for any address
assigned on the egress interface other than the Care-of Address valid on
the visited link.

> *If* you want to add this, putting the prefix options that failed in 
> the BAck would be the easiest and it doesn't make any packet any 
> larger when things are working (since it that case all prefixes were 
> ok).

I see.  I personally do not need this feature because I favor a lot the
implicit mode.  If on the other hand the group feels this is needed I
can understand why: prefix-BAck may help a lot in debugging when using
explicit mode.  However, IMHO, prefixes in BU/BAck is duplicating
functionality of routing protocols, and in the OSPF particular case the
Links State Acknowledgements include the acknowledged LSA's, which is to
me similar to putting prefixes in the BAck.

Alex

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 25 Oct 2004 14:18:50 -0700

> assigned on the egress interface other than the Care-of Address valid on

*If* that's what the WG wants to do I suggest being very specific in the 
text by saying something like this:
While away from home the MR MUST NOT send any NA for the Home Address on 
the visited link. In addition, it MUST NOT use the Home Address as the 
source address for any Neighbor Discovery packet sent on the visited link.
The reason for these restrictions is to prevent the creation of a 
Neighbor Cache entry for the HoA on the neighbors on the visited link; 
the neighbors should communicate with the MR via its Home Agent.
Note that these restrictions apply to Neighbor Discovery on the visited 
link and do not apply to the link which is the tunnel between the MR and 
the HA.

   Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 25 Oct 2004 16:01:25 -0700

> sections, then this would be ok.

okay. here is the text

    The Home Agent sets up forwarding for each of these prefixes
    to the Mobile Router's Care-of Address, once it has verified that
    the Mobile Router is authorized to route to those prefixes.  Section
    6.1.2 describes a mechanism by which the Home Agent can verify if
    a Mobile Router is authorized for a prefix.

> I don't know what the overhead would be; the IANA needs to edit the 

with the recent delays we have had with IANA assignments, I am not
sure I want to do this.

>     143 Forwarding Setup Failed (prefixes missing)

this is fine with me.

> the prefix option is defined.

section 4.3 defines the Mobile Network Prefix. I think this text
should come under processing the Binding Update. so in section 6.2
lets change the text to say the HA should not create the routes.

        If the Home Agent fails to setup
        forwarding to all the prefixes listed in the Binding Update, then
        it MUST NOT create routes to any of the prefixes, reject the
        Binding Update and send a Binding Acknowledgement with status set
        to 141 (Invalid Prefix).

> for the HoA, since it would be harmless.)

how about we change the text to the following

    However, the
    Mobile Router SHOULD reply with Neighbor Advertisements to Neighbor
    Solicitations received on the egress interface only for addresses
    valid on the visited link.

while I agree it is harmless, is there a use of allowing the MR to
send a solicited NA for the HoA on the visited link? if some MR
really wants to do it, maybe it can ignore the 'SHOULD' and do it?

>>> its home address, which the upper MR has no knowledge of, in the 
>>> inner header?
>>
>>
>>

ah.. now I understand. the current text says

    In case the Mobile

the text "has to forward the decapsulated packet" means the IP-in-IP
packet was addressed to the MR. that is why it is decapsulating and
forwarding the inner packet.

but I agree it should be made more explicit. how about the following?

    In case the
    Mobile Router receives a IP-in-IP tunneled packet from a node in the
    Mobile Network, with the destination address on the outer IPv6 header
    set to the Mobile Router and the Mobile Router has to forward the
    decapsulated packet, it SHOULD perform the above mentioned checks on
    the source address of the inner packet.

> (And I think IS-IS and RIPv2 has the same issue as OSPF here.)

can you propose some text here? I couldnt come up with anything
that satisfied even me.

> That's the gist of it (I didn't check the above text against the 

Erik, I did some research. does not look like the above text
needs to appear in the draft. RFC 3668 seems to say, it is enough
if the draft points to http://www.ietf.org/ipr. it appears to me
that the following two paragraphs are sufficient.

in the "Status of This Memo" section

    By submitting this Internet-Draft, each
    author represents that any applicable patent or other IPR claims of
    which he or she is aware have been or will be disclosed, and any of
    which he or she become aware will be disclosed, in accordance with
    RFC 3668.

in the "Intellectual Property Statement" section

    Copies of IPR disclosures made to the IETF Secretariat and any
    assurances of licenses to be made available, or the result of an
    attempt made to obtain a general license or permission for the
    use of such proprietary rights by implementers or users of this
    specification can be obtained from the IETF on-line IPR repository at
    http://www.ietf.org/ipr.

please correct me if I am wrong.

Vijay

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 25 Oct 2004 16:47:00 -0700

ok

ok

> really wants to do it, maybe it can ignore the 'SHOULD' and do it?

Pascal brought up the issue of unsolicited NAs as well, and I added that 
other ND messages can create state (e.g. sending a NS with the source 
being the HoA). So the question is how strong does the WG want to make 
the prohibition. In any case, independent of what it covers and whether 
it is a MUST or a SHOULD, it would be useful to add a sentence about the 
problem the way I suggested to Pascal (that way folks know what 
violating e.g. a SHOULD would imply).

>    the source address of the inner packet.

WFM

>> acceptable. So the note needs to be about the increased load 
>> especially for large IGP domains.

When the mobile router participates in an IGP such as OSPF, the fact 
that the MR-HA connectivity will change over time can have a significant 
performance impact, especially for large IGP domains.
The performance impact is two-fold:
  - the changes of reachability for the MR-HA tunnel can potentially be
    flooded to all the routers in the routing domain, causing additional 
load on the routers
  - each time the MR re-establishes the tunnel to the HA it will
    need to synchronize all the LSAs

Therefore, it is RECOMMENDED that all-but the smallest routing domains
use OSPF areas [XXX should we also say something about IS-IS?] to limit 
the propagation of routing information when the MRs come and go.
[add rest of text in edited form]

> please correct me if I am wrong.

You're right. I'd missed that the "has been notified" language is 
removed from the new boilerplate.

    Erik

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 25 Oct 2004 18:01:29 -0700

> violating e.g. a SHOULD would imply).

you mean Alex? I will follow up on that thread.

> [add rest of text in edited form]

appendix B.2 is specifically about running OSPF. I dont this we
need to talk about IS-IS here. (I anyway dont know enough about
IS-IS).

here is the entire text.

B.2. OSPF Area Considerations

    When the Mobile Router participates in an IGP such as OSPF with its
    Home Agent, the fact that the Mobile Router-Home Agent connectivity
    will change over time can have a significant performance impact,
    especially for large IGP domains.  The performance impact is
    two-fold:

     -  The changes in the reachability of the Mobile Network can
        potentially be flooded to all the routers in the routing domain,
        causing additional load on the routers.

     -  Each time the Mobile Router re-establishes the tunnel to the Home
        Agent, the Home Agent would need to synchronize all the LSAs.

    Therefore, it is RECOMMENDED that all-but the smallest routing
    domains use OSPF areas to limit the propagation of routing
    information.

    The following should be considered when the Home Network is
    configured for OSPF areas.

    For a more detailed discussion on configuring a Home Network for NEMO
    Basic Support, please see [18].

    One disadvantage of running OSPFv3 with NEMO Basic Support is that
    there is a possibility that the Mobile Networks will be told of the
    topology of the entire Home Network, including all the fixed and
    mobile routers, while the only thing the Mobile Routers might really
    need is a default route through the Home Agent.

    To reduce the amount of routing protocol messages received by a
    Mobile Router, one can configure each bi-directional tunnel to a
    Mobile Router as a separate area.  But this requires that the Home
    Agent support a large number of OSPF areas if it supports a large
    number of Mobile Routers and might not be possible with most router
    implementations.

    Another option is to configure multiple areas on the Home Link and
    group a number of Mobile Routers into each area.  This reduces the
    number of areas that a Home Agent needs to support, but at the same
    time reduces the amount of routing protocol traffic that a Mobile
    Router receives.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 25 Oct 2004 18:09:21 -0700

I dont think I want to prohibit MR from sending solicited NAs
on the visited link for the HoA. maybe we will find a use for it. :)

> While away from home the MR MUST NOT send any NA for the Home Address on 

we shouldnt add something like this.

> In addition, it MUST NOT use the Home Address as the 

the right place for this language is RFC 3775. (I think it already
talks about not using HoA as source address for packets sent to
the visited link directly).

I think it is enough to say

    However, the

and stop there. the 'SHOULD' can be ignored if somebody wants to.

Vijay

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 25 Oct 2004 19:12:23 -0700

> you mean Alex? I will follow up on that thread.

Yes. Sorry for the confusion.

>    time reduces the amount of routing protocol traffic that a Mobile

Good enough.

   Erik

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 26 Oct 2004 19:48:36 +0200

Vijay Devarapalli wrote:
> Erik Nordmark wrote:
>>> I am fine with the change, but this might mean sending the 
>>> document back to IANA. IANA has already done the assignments. 
>>> http://www.iana.org/assignments/mobility-parameters. and they 
>>> call it "Forwarding Setup failed". maybe we can avoid this 
>>> change. (?)
>> 

A quick way to clarify how much impact this may have may be to talk
face-to-face during IANA "office hours" at the next meeting, a suggestion.

Alex

> From: "IANA" <[email-masked]>
> To: <[email-masked]>
> Date: Wed, 20 Oct 2004 14:40:26 -0700
> Subject: IANA "Office Hours" at IETF-61 in Washington, DC.
> 
> Greetings!
> 
> The IANA will be holding "Office Hours" at the IETF-61 in Washington,
> DC. Our experience in San Diego was a success and many people
> requested we hold office hours again. This will continue to give
> everyone an opportunity to discuss IANA Considerations in your
> documents, as well as ask any questions that you may have.
> 
> The IANA will have a table near the IETF registration area, staffed
> during the following hours:
> 
> Monday - Wednesday, 0900 - 1600 
> 
> Please stop by and say hello.  
> 
> Thank you and see you in DC!
> 
> IANA (Michelle Cotton and Doug Barton)
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf-announce