Subject: [MEXT] Nits for draft-ietf-mext-nemo-v4traversal-00

From: <[email-masked]>
Date: Wed, 30 Jan 2008 13:21:20 +0200

I also have some notes related to the use of IPsec, but I'm 
sending them in a separate message. All the comments below are 
basically just semi-editorial nits, and should be easy to fix.

1) Section 2.1, "For instance, if the service name is "mip6ha" and
the protocol name is "ipv6" for the SRV record, the mobile node
SHOULD send a DNS request with the QNAME set to
"mip6ha.ipv6.example.com"."

The service name specified in RFC 5026 is "mip6" (not "mip6ha");
and the QNAME is missing two underscores.

2) Section 2.3.2.2, "All entries MUST point to the mobile node's
IPv4 care-of address included in the binding update message." Since
this section is about the private addresses case, it's not the
address inside the binding update message, but rather the outer
tunnel address that gets used, right?

3) Section 2.3.2.2, "The mobile node needs to maintain the NAT
bindings for its current IPv4 care-of address. This is done through
sending the binding update regularly to the home agent."

4) Section 4.1 describes the UDP encapsulation formats as :

   IP (v4 or v6)
   UDP
   IP (v4 or v6)
   Other headers

Later, the text says that "UDP encapsulation MUST NOT be used when
the mobile node is located in an IPv6-enabled link". Thus,
shouldn't the first line be simply "IP (v4)"?

5) Section 4.2, "The source address of the IPv6 packet is the
mobile node's IPv6 home address." and later "When the home agent
receives the encapsulated binding update it compares the IPv4
address of the source address field in the IPv4 header with the
IPv4 address in the source address of the IPv6 header." There two
sentences seem to contradict each other.

6) Section 4.2, the BAck packet is missing ESP.

7) Section 4.3, "It should be noted that a mobile node that does
not need to be reachable (i.e. only cares about the session
continuity aspect of Mobile IP) does not need to refresh NAT
binding. In this case, the mobile node would only be able to
initiate communication with other nodes." Yes and no: if the MN
doesn't refresh the NAT bindings at all, it won't be able to just
initiate communications either (since when it attempts to initiate
communications, the NAT will probably allocate a different port,
and the HA state will be wrong). So even if MN does not refresh NAT
bindings _all the time_, it has to do so when it wants to initiate
communications (after a long period of being idle). (This might be
slightly tricky to implement correctly, BTW.)

8) Section 4.4.1 and 4.5.1: the packet formats figures should show 
"[UDP header [TLV-header]]" instead of just "[UDP header]".

9) Section 5, "it has the same UNSAF vulnerabilities associated
with RFC 3519"; it would be more accurate to say "the same
NAT-related security vulnerabilities as RFC 3519", as neither this
nor RFC 3519 is an "Unilateral Self-Address Fixing" (UNSAF)
mechanism.

10) There's no IANA considerations text for TLV-header "Type" field,
just statement that "other values may be assigned in future".
By whom, and subject to what requirements?

11) There's no IANA considerations text for IPv4 address
acknowledgement option "Status" field. Since it's clearly intended
that other values may be assigned in the future, this document
should state by whom, and subject to what requirements.

12) RFC 3519 is mentioned, but not listed in references.

13) From idnits:

No 'Intended status' indicated for this document; assuming 
Proposed Standard

The document seems to lack the recommended RFC 2119 boilerplate, 
even if it appears to use RFC 2119 keywords. 

Line 1226 has weird spacing: '...ulation  for o...'

Using lowercase 'not' together with uppercase 'MUST' is not an accepted
usage according to RFC 2119.  Please use 'MUST NOT' (if that is what you
mean).

Missing Reference: 'DNAv4' is mentioned on line 1010, but not defined

Outdated reference: draft-ietf-mip6-bootstrapping-split has been
published as RFC 5026

Unused Reference: 'IPv6' is defined on line 1291, but no explicit
reference was found in the text

Unused Reference: 'KEYWORDS' is defined on line 1301, but no explicit
reference was found in the text

Unused Reference: 'SEC' is defined on line 1304, but no explicit
reference was found in the text

Unused Reference: 'MIPv4' is defined on line 1330, but no explicit
reference was found in the text

-------

Best regards,
Pasi

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