Subject: [MEXT] AD review of mext-nemo-v4traversal

From: Jari Arkko <[email-masked]>
Date: Fri, 22 Aug 2008 17:23:07 +0300

I have reviewed this specification. I did not find any showstoppers, but 
there were a number of issues that need to be addressed. I am expecting 
a revised draft and some discussion about question marks below.

Please find my detailed comments below. First the technical ones:

> Scenario 3: Home Agent behind a NAT
I think you are making your life unnecessarily hard. Is there a true 
demand for this?

> 2)
> configure one public address and make the home agents share the
> public address.

How would this work if the NAT happens to forward one BU to one home 
agent and the next BU the a second one?

Please explain better or remove.

> Another possible solution is to designate one home agent
> on the home link for IPv4 traversal.  The NAT device should associate
> that home agent with the public IPv4 address configured on it for v4
> traversal.  In all cases above, both the 'AAAA' and 'A' records
> returned for a particular name MUST correspond to the same physical
> home agent
The first and third sentences seem to be in conflict. If one HA is used 
for IPv4, then presumably the other ones are used for IPv6. If so, when 
a mobile node moves from IPv6 care-of address to an IPv4 care-of 
address, it has to switch the home agent.

>    When a mobile node acquires both IPv4 and IPv6 care-of addresses ws at
>    the foreign network, it SHOULD prioritize the IPv6 care-of address
>    for MIP6 its binding registration.  The mobile node MUST NOT register
>    both IPv4 and IPv6 care-of addresses to its home agent.

This is the priority, but its also likely to have the same problems as 
we have with dual stack hosts getting long timeouts due to trying out 
broken IPv6 connectivity. Look at the Stuart Cheshire's technical 
plenary presentation, for instance. I would suggest that you have an 
explicit specification of the recovery mechanism: trying out both in 
parallel, trying one first and then falling back -- I do not have the 
details but you have to have a recovery mechanism.

Similarly, it would be very useful if the document contained better 
instruction about when a mobile node sets the F flag. If there is no NAT 
but a firewall, the mobile node may wish to use UDP encapsulation. Would 
it be possible to have the mobile node revert back UDP encapsulation if 
the direct encapsulation does not appear to be working?

> Refresh Time
>
> A suggested time (in seconds) for the mobile node to refresh the
> NAT binding.  If set to zero, it is ignored.  If this field is set
> to all 1s it means that keepalives are not needed, i.e., no NAT
> was detected.
>   
How would a home agent know what behaviour to expect from a NAT in a 
visited network (e.g., user's home DSL box)?

Please provide additional discussion on how to set this field, what the 
manageability considerations are, etc.

> T
>
> This flag indicates, when set, that the sender of the binding
> acknowledgement supports the TLV- tunnel format.
>   

Does this really signal support or that the use of the requested TLV 
format will be granted?

Why this matter is what happens when the BU has T=0. If the home agent 
supports TLV, does it set T=1 or T=0?

(I later found an explanation about this in Section 5.1. Maybe it should 
be clarified earlier.)

> The Type field MUST NOT be
> assigned the values 4 or 6 to make sure that the receiver can tell
> the difference between the Type field and the IP version field in a
> packet that contains an IP header after UDP. 

See RFC 4928 and 
http://www.iana.org/assignments/version-numbers/version-numbers.xhtml

In short, other protocols have done in the past, and restricted 
themselves to values 0 and 1, in order to allow for the (admittedly 
unlikely) allocation of a new IP version number.

Please consider the same approach here.

(And why do we have to distinguish between the TLV and IP -- I thought 
you negotiated the use of TLV?)

> However, UDP MUST NOT be used to encapsulate
> the binding update message when the mobile node is located in an
> IPv6-enabled network. 

MUST NOT is quite strong here. I do not think the reasons for using MUST 
apply here. And indeed, there might be future needs to employ UDP over 
IPv6 as well, if there was a (bad) firewall that only support UDP and 
TCP passthrough.

> The IANA should allocate and permanently register new TLV-header
> types and Status field values from IETF RFC publication.  This is
> for all RFC types including standards track, informational, and
> experimental status that originate from the IETF and have been
> approved by the IESG for publication.
>   

Please use RFC 5226 terminology instead. I think you mean: New 
TLV-header types and Status field values are allocated via IETF Review 
[RFC5226].

Missing things:

- Is it really the case that this document does not need to reference 
RFC 4877, even if both talk about the encapsulation formats?

- What about IKEv2, RFC 4306?

- There is no discussion of the interaction between NAT detection & 
traversal in IPsec vs. in DSMIP.

- There is no discussion about procedures for IPv4 addresses "returning 
home". You could rule that not supported, but even in that case it 
should at least be mentioned.

Editorial:

> In this specification, extensions are defined for the binding update
> and binding acknowledgement.  It should be noted that all these
> extensions apply to cases where the mobile node communicates with a
> Mobility Anchor Point (MAP) as defined in [RFC4140 <http://tools.ietf.org/html/rfc4140>].  The
> requirements on the MAP are identical to those stated for the home
> agent, although it is unlikely that NAT traversal would be needed
> with a MAP as it is expected to be in the same address domain.
>   
First, 4140 should be 4140bis. But I am curious that you mention HMIP 
and not any of the other things that might apply equally well, such as PMIP.

> NAT box
s/NAT box/NAT/

>  The security implications of this
>    mechanism are discussed in the security considerations section.
>   
This appears in Section 3.3.1. This does not seem like a very useful 
statement. Everything in this document is hopefully discussed in the 
security considerations section!

Consider removing the statement.

> When a mobile node acquires both IPv4 and IPv6 care-of addresses at
> the foreign network, it SHOULD prioritize the IPv6 care-of address
> for MIP6 its binding registration.
... for its MIP6 binding ... ?

> If no NAT
> is detected between the mobile node and the home agent, the mobile
> node assumes that it is in a foreign network that supports IPv4
> public addresses.  Otherwise, the mobile node assumes that private
> addresses are used in the foreign network.  Note that this assumption
> is only valid for the purposes of the signaling presented in this
> specification.  A mobile node SHOULD NOT assume that its IPv4 address
> is globally unique if a NAT device was not detected.

This was very hard to parse. What is "supports IPv4 public addresses"? 
How is that different from "MN's IPv4 is globally unique"? Isn't the 
only thing that you need to know here: can the mobile node be reached 
from the home agent by sending an IPv4 packet to its address?

> 3.3.2.2. Foreign Network Supports IPv4 Only (Private Addresses)

I was surprised that this section says nothing about keeping the port 
numbers in the binding cache entry. Section 5.2 talks about this, but 
that is much later.

> Additionally, this option can include an IPv4 home address in the
> case of Dynamic IPv4 home address configuration (i.e., if the
> unspecified IPv4 address was included in the binding update).
Can? It always will, right? s/can include/includes/ Or are you 
considering some error case. Please be more specific here.

> To
> avoid confusion in the correspondent node, the mobile node SHOULD
> deregister its binding with each correspondent node by sending a
> deregistration binding update.
This text (and surrounding paragraph) in Section 6.1 feels like it is in 
the wrong place. This has nothing to do with IPsec and IKE, its part of 
the basic behaviour of the mobile node.

> .. requires
> an option type.  This option is included in the Mobility header
> described in [RFC3775].
This was hard to read. Maybe: ... requires a new option type allocation 
for a mobility option [RFC 3775].

Jari

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 23 Aug 2008 10:20:40 +1000

> I think you are making your life unnecessarily hard. Is there a true

=> Not in my opinion, but we discussed this for a long time on the list and
some people thought it was needed. This paragraph you quote doesn't do
anything though, it simply mentions the scenario and says that the spec
assumes a public IPv4 address. The offending text is below.
> Please explain better or remove.

=> This is not right of course, not sure how it slipped into the text.

> address, it has to switch the home agent.

=> Correct. Although that scenario is not seen as important, I would prefer
to remove those three sentences from the spec.

> plenary presentation, for instance.

=> Oh, I'm aware of the problems with IPv6 connectivity *today*. However, I
really don't think we should design the spec around what can be seen as a
transient problem. I mean, how many people outside IETF know about those
problems? The decision about CoA selection has profound implications that
will stay in the spec for a long time.
IPv6's connectivity issues are, IMO, clearly tied to the fact that it's not
used today. Once it's used enough for this spec to be deployed, I doubt very
much we will be discussing how slow it is compared to IPv4. So, I'm
reluctant to add further complication to CoA selection based on this issue.

The recommendation to use IPv6 first follows RFc 2893 (now 4213).

I would suggest that you have an
> details but you have to have a recovery mechanism.

=> You mean ICE? :) seriously, how complicated do you want it to be?
We could do a "try v6 and if BU is rejected/timed out three times then try
v4" is that ok? 

> the direct encapsulation does not appear to be working?

=> Sure, section 5.1 says:
  The mobile node can request to always use
   UDP encapsulation by setting the F flag in the binding update.  If
   the home agent does not agree to the request, it MUST reject the
   binding update with the new Status code:

      144 Cannot force UDP encapsulation

   Alternatively, the home agent can force UDP encapsulation by setting
   the F flag in the NAT detection option included in the binding
   acknowledgement.

> visited network (e.g., user's home DSL box)?

=> It doesn't, and that's why the default is the least common denominator.

> manageability considerations are, etc.

=> There is no clever solution for this, but what we can say is if the HA
doesn't know better, it should use the default value in the spec. Is this ok
with you?

> Please consider the same approach here.

=> Sure, we only use 1 anyway.

> you negotiated the use of TLV?)

=> The BU is sent in IP only, so you need to tell the difference between a
BU and a traffic packet.

> IPv6 as well, if there was a (bad) firewall that only support UDP and

=> But there are many scenarios where we can do things to cheat a firewall,
is this really a good idea? What if the FW only allows port 80? If the
firewall is "bad" in our eyes, may be there is a reason for that in someone
else's eyes.
One of the reasons for the MUST NOT was to simplify the security scenarios
by eliminating the two scenarios of IPv6/UDP/IPvx. But I agree that it might
not, strictly speaking, comply to the definition of a MUST.

> TLV-header types and Status field values are allocated via IETF Review

=> Ok.

> - What about IKEv2, RFC 4306?

=> Ok 

> traversal in IPsec vs. in DSMIP.

=> Could you elaborate? What needs to be discussed?

> should at least be mentioned.

=> ok.

>> Mobility Anchor Point (MAP) as defined in [RFC4140
>> <http://tools.ietf.org/html/rfc4140>].  The
> First, 4140 should be 4140bis.

=> ok.

  But I am curious that you mention HMIP
> and not any of the other things that might apply equally well, such as PMIP.

=> Well, this line was written before PMIP, but anyway PMIP has its own
accompanying spec for DSMIP, which refers to this spec. Of course a number
of things in this spec don't apply to PMIP so it's best to not confuse
people. Also, while on the topic, FMIP use with DSMIP would be a bad idea of
course unless one writes a separate spec detailing how they could be used in
very specific scenarios.

> ... for its MIP6 binding ... ?

=> ok.

> from the home agent by sending an IPv4 packet to its address?

=> yes.

> numbers in the binding cache entry. Section 5.2 talks about this, but

=> The scenarios sections are supposed to just list the scenarios, if
anything I think we should remove the solutions from those sections.

> considering some error case. Please be more specific here.

=> ok.

> the basic behaviour of the mobile node.

=> ok

> for a mobility option [RFC 3775].

=> ok.

---

From: Jari Arkko <[email-masked]>
Date: Sat, 23 Aug 2008 08:54:03 +0300

Thanks for your prompt response. Inline for the things that need further 
discussion:

> assumes a public IPv4 address. The offending text is below.

OK

> much we will be discussing how slow it is compared to IPv4. So, I'm

I am less concerned about it being slow than about it being broken. 
Look, the problems of bad IPv6 connectivity from a random visited 
network are going to be with us for a long time. It is in your best 
interests to make your protocol resilient against these problems.

> We could do a "try v6 and if BU is rejected/timed out three times then try

I think it is a start. But I would not approach this from the point of 
view of complexity. You need to make this work.

 From my perspective the requirement is:

Upon arrival to a new visited network, choose between UDP encap/plain 
v4/plain v6 so that you take into account:
- NATs
- Firewalls
- Possibility of broken v6 connectivity, i.e., routers claim global 
connectivity but you cannot reach your HA

And you should be able to make the choice within seconds or sooner.

>    the F flag in the NAT detection option included in the binding

Yes, the document currently allows this behavior. What I am saying is 
that the document should specify what logic the mobile node uses in 
making this happen. For instance, if you have tried without UDP and you 
are not getting anything back.

> => It doesn't, and that's why the default is the least common denominator.

Ok, but please explain this.

> doesn't know better, it should use the default value in the spec. Is this ok

As I recall the text, you had a value for saying "unknown", right? If 
that is the default then you can say that the HA can include a value 
when it knows what network the visited network is. E.g., I assume in 
some 3GPP environments you might have enough information to put in a value.

> => Sure, we only use 1 anyway.

Yes, but this will affect the IANA considerations. You will have just 
one value left, also.

> => The BU is sent in IP only, so you need to tell the difference between a

Ok. Please explain this in the spec, if it is not there already.

> not, strictly speaking, comply to the definition of a MUST.

Right. We don't need to specify the UDP-over-IPv6 case now. Just change 
the keyword to a SHOULD.

> => Could you elaborate? What needs to be discussed?

IPsec and IKE have a NAT detection and traversal mechanism. From having 
read your spec I do not understand how or whether it works with the 
mechanisms of this spec. For instance, if you run IKE(v2), are you 
expecting it to detect NATs on its own or not.

> course unless one writes a separate spec detailing how they could be used in

OK

Jari

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 23 Aug 2008 17:03:05 +1000

Thanks Jari, 

I'll address your comments. The big one that we need to think about
carefully is the order of selection for the transmission of the BU. I.e. v4
Vs v6 and UDP encap in the absense of NAT. I'll work on text and send it it
out for the list to review.
Of course I'll do te same for the rest, but this one is the most
significant. 

Hesham

---

From: Jari Arkko <[email-masked]>
Date: Sat, 23 Aug 2008 10:24:33 +0300

Thanks. Just one clarification about the UDP vs. v4 vs. v6 issue. I 
think your *order* is already correct. I'm not asking you to change the 
order. What I am asking, however, is that you a specified recovery 
mechanism in case one does not work.

Jari

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 23 Aug 2008 18:20:20 +1000

> mechanism in case one does not work.

=> Understood. I just think the tricky things are going to be related to
movement detection. There is little distinction in MIPv6 between the
"initial" BU and the following ones, and of course the tricky question is
how the MN knows that it should not do the trial and error everytime it
moves. Meaning, imagine scenario where a MN gets 2001::1, 2002::1 and
63.1.1.1. Lets say the MN decided both v6 addresses and neither worked, then
it moved to a new link, if it has to do this whole procedure again then it's
a disaster for movement detection. It's really difficult to know how and
when to blacklist an address family because you really never know why the BU
failed.

You can try the various scenarios with the 3 address example I gave but I
think you get the idea of why I think this is complex.

Hesham

---

From: Jari Arkko <[email-masked]>
Date: Sun, 24 Aug 2008 21:27:09 +0300

I do realize it is complex, but is also necessary in order to give a 
good user experience.

I do not think you should blacklist address families. Everything should 
happen on a per-visited network basis (you may want to specify 
remembering what the situation was in the last few networks, if you want).

Jari

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 25 Aug 2008 15:29:11 +1000

> I do realize it is complex, but is also necessary in order to give a

=> Me too.

> remembering what the situation was in the last few networks, if you want).

=> I think you MUST remember what happened otherwise you can end up with a
few seconds for movement detection. But of course, the other side of that is
that what happened in the last visited network does not necessarily have any
bearing on this new network....
It just gets extremely complex if you want a proper solution. I don't even
know if it's doable properly. The easy way (and of course not really
correct) is to try v6, then v4 and stick to it, while trying v6 again in
parallel periodically (say once an hour). I'll write something up as a
starting point.

Hesham

---

From: Jari Arkko <[email-masked]>
Date: Mon, 25 Aug 2008 15:30:50 -0700

Hesham,

> few seconds for movement detection.

Yes.

> But of course, the other side of that is

Right.

> parallel periodically (say once an hour). I'll write something up as a

I do not see evidence of this being an unsolvable problem. You apply 
either parallel or sequential trying of the different alternatives on 
each previously unknown network, and then keep state about the networks 
for some specified amount of time.

Jari

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 26 Aug 2008 10:27:29 +1000

> for some specified amount of time.

=> My point is that keeping historical state is actually not really correct.
It's a guess (that has no strong basis) that since IPv6 didn't work in the
last network, it probably won't work again! It's meaningless. But we need to
do that in order to avoid the potential movement detection delay. So the
ultimate result is sub-optimal whichever way you look at it (i.e. Selecting
a v4 address when a v6 one should've been selected, especially if that v4
address is private, or breaking movement detection).
What I was trying to say is that I don't see a solution that provides the
optimal choice with a high degreee of certainty (of course with the
exception of the initial BU).

Hesham

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 25 Aug 2008 21:45:32 -0400

Hi Jari, Hesham,

>From what I remember, there were a few people who insisted on supporting
the scenario where the home agent is behind a NAT. There were extensive
discussions both in the mip6trans design team and on the MIP6 mailing
list. See
http://people.nokia.net/vijayd/mip6trans/mip6trans_scenarios.txt for a
description of the scenarios that the design team concluded on. 

The solutions were explicitly added to avoid having to standardize more
complicated solutions. There, I would like to keep the existing text
related to this scenario.

> Please explain better or remove.

Well, the NAT should be capable of looking into the binding update
message, and then based on either the IPv4 care-of address or something
in the binding update itself, decides which of the internal home agents
gets the message. This would be similar to a load balancer function. The
information in the binding update should be sufficient for the NAT to
consistently forward the binding updates from a particular mobile node
to the same home agent. I remember we had discussions on this. The text
we have currently is supposed to reflect this, without going into too
much detail.

> for IPv4, then presumably the other ones are used for IPv6. 

No. The above sentence says one of the home agents can be designated for
v4 traversal. That means it supports DS-MIPv6, which again means that
the home agent can support both IPv4 and IPv6 home addresses and care-of
addresses. 

> If so, when 

The mobile node shouldn't have to.

Vijay