[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[netlmm] A review of draft-ietf-netlmm-pmip6-ipv4-support-16
Hello,
I've done a quick review of draft-ietf-netlmm-pmip6-ipv4-support-16 at
AD request. I have only vague understanding of PMIP6 so take this
with a grain of salt.
The document is written in a manner that should be easy to implement,
but a bit challenging to verify from the spec point of view for
correctness and that all the corner cases are dealt with. This is an
OK documentation decision. The spec also contains a bit of
unnecessary repetition, but this is not harmful as long as the length
doesn't grow much or introduce inconsistencies.
I wonder at the original PMIP6 design decision that MAGs establish
tunnels to LMAs dynamically. Are there really so many potential LMAs
for each MAG that these could not be set permanently, as a separate
specification or independent of MNs' behaviour? A lot of space and
complexity in the spec is introduced by verifying whether the MAG-LMA
tunnel has been set up. This also creates delays and complexities
(users' packets dropped until the tunnel is up) when the tunnel does
not exist yet, tearing down tunnels, etc. A simpler alternative
could have been that the MAG establishes tunnels when its MAG services
are started and they will always remain up. But again, the horse has
already left the barn.
The specification only supports unicast; this is not stated in the
spec.
The security considerations section is a bit weak, but I don't have
the energy to comment on it in detail.
Below are some of the issues or unclear things I spotted. Sorry for
not having time to write them up more nicely.
substantial
-----------
o The local mobility anchor and the mobile access gateway MUST be
configured with IPv6 globally unique addresses, even when they are
in IPv4-only network. These addresses can be of the type Unique
Local IPv6 Unicast Address [RFC-4193], IPv6 Global Unicast Address
[RFC-3587] or IPv4-mapped IPv6 address [RFC-4291].
.. "Local IPv6 unicast addresses" are not IPv6 globally unique addresses,
otherwise the term would be an oxymoron, right? Also, IPv4-mapped IPv6 are
not necessarily globally unique. Further, it is not clear why IPv4-mapped
IPv6 address is not even allowed in the spec. I'd remove it here
completely. Some other places in the spec also mention "IPv6 globally
unique addresses" and I frown a bit when I see it. Aren't you really just
referring to non-link-local addresses, or addresses that must be unique
within the PMIPv6 domain? (Hopefully, these should be global, of course, but
that's a separate topic.)
In S 1.1 Assumptions:
o The mobile node can obtain an IPv4 address for its attached
interface. Based on the type of link, it may be able to acquire
its IPv4 address configuration using standard IPv4 address
configuration mechanisms such as DHCP [RFC-2131], IPCP [RFC-1332],
IKEv2 [RFC-4306] or static address configuration.
But in S 3.4:
Section 3.4 identifies these interactions for supporting DHCP based
address configuration.
.. Either the assumptions should say that only DHCP is supported, or S 3.4
and the rest of the spec should be clearer how other mechanisms would work,
or that they are beyond the scope of this spec.
In S 3.2.4:
However, if the link between the
mobile node and the mobile access gateway is a point-to-point
link, then the mobile access gateway is not required to support
proxy ARP.
Yet in S 3.2.3.2 (also 3.4.2):
However, since the link between
the mobile access gateway and the mobile node is a point-to-point
link, implementations will be able receive any packets sent to the
default router address without having to explicitly configure the
default router address on its interface.
... the spec is internally inconsistent. It appears that the requred
assumption is that the link is point-to-point, but at least one place
(3.2.4) is not firm about that design decision, and it should be.
In S 3.2.4:
When receiving an ARP Request, the local mobility anchor
SHOULD examine the target IP address of the Request, and if this
IP address matches the mobile node's IPv4 home subnet, it SHOULD
transmit a Proxy ARP Reply.
.. I suppose proxy ARP should reply for every address in the subnet?
I suppose because proxy ARP behaviour is not specified here, RFC 925 needs
to be a normative reference.
In S 3.4:
o The DHCP server or the DHCP relay agent configured on the mobile
access gateway is required to have an IPv4 address for exchanging
the DHCP messages with the mobile node. This address is the
mobile node's default router address provided by the local
mobility anchor. Optionally, all the DHCP servers co-located with
the mobile access gateways in the Proxy Mobile IPv6 domain can be
configured with a fixed IPv4 address.
.. I'm not sure if I understand the last scenario. The only way the address
could always be the same would be either using anycast or that each MAG is
behind a different NAT, isolated from each other. Or am I missing
something? (I suppose so...)
In S 3.4
* However, if the mobile node is capable of performing handoff
between interfaces, as per [RFC-5213], the interface identifier
in such scenarios needs to be an identifier that is not tied to
any of those interfaces. The identifier must be a stable
identifier which remains the same through out the mobile node's
attachment in that Proxy Mobile IPv6 domain. This identifier
must remain fixed for a given binding. This identifier in some
implementations can be the identifier associated to a virtual
interface, that is abstracting the physical interfaces.
.. aren't you basically saying that the prior point about using hardware address
based identifier doesn't work? Even though the higher-level bullet point just
describes these as "considerations", shouldn't you really be describing
the requirements (it seems a stable identifier must be used, otherwise
handoffs don't quite work; it might be worth describing how they will not work,
and how to mitigate that).
Am I reading the spec correctly that the only reason why a stable Client Identifier
is not mandated by the spec is because implementations out there don't generally
support it and no changes to the v4 node are allowed? If this reading between
the lines is true, is there a more complete solution possible or feasible?
In 3.4.2:
o Once the mobile access gateway intercepts the DHCP message from
the mobile node to the DHCP server, it can verify if the mobile
node is negotiating the same IPv4 address that the local mobility
anchor allocated for that mobile node. If the address in the
DHCPREQUEST message does not match with the IPv4 address allocated
for the mobile node, then the mobile access gateway SHOULD
silently drop the DHCP message.
... But earlier was slightly different recommendation, is there a reason why
these are different:
o On receiving a DHCPOFFER message from the DHCP server, the mobile
access gateway will ensure the assigned address is currently
assigned by the local mobility anchor to that mobile node. If
this address is different from what is assigned to the mobile
node, then the mobile access gateway will drop the DHCPOFFER
message and an administrative error message will be logged.
4.1.3.3. NAT Presence Detection
When the transport network between the local mobility anchor and the
mobile access gateway is an IPv4 network and if the received Proxy
Binding Update message was sent encapsulated in IPv4 UDP header, the
local mobility anchor performs the NAT Presence Detection as
specified below.
On receiving the Proxy Binding Update message encapsulated in an IPv4
UDP packet, the local mobility anchor, if it detects a NAT on the
path, will send the Proxy Binding Acknowledgment message with the NAT
Detection Option. The presence of this option in the Proxy Binding
Acknowledgment is an indication to the mobile access gateway about
the presence of NAT in the path. On detecting any NAT in the path,
both the local mobility anchor and the mobile access gateway will set
the encapsulation mode of the tunnel to IPv4-UDP-based encapsulation.
The specific details around the NAT detection and the related logic
are described in DSMIPv6 specification [RFC-5555].
.. this seems to be saying that if LMA receives an IPv4-UDP encapsulated
PBU, only then it will do NAT detection, the result of which would be
starting to use IPv4-UDP encapsulation. What am I missing here, isn't this
a circular definition?
In S 4.3.2:
MAG SPD-S:
- IF interface = IPv6 tunnel to LMAA_1 &
local_address != Proxy-CoA_1 &
remote_address != LMAA_1 & proto=any
Then use SA ESP tunnel mode
yet:
MAG's IPsec module
:
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: ESP header in tunnel mode
: IPv4/v6 header (src= MN-HoA, dst= CN)
: Payload
... are Proxy-CoA_1 and LMAA_1 above different from Proxy-CoA and LMAA
below? How, I'm not following the designations here, the ones with _1
weren't explained? Do SPDs written here have the two conditions
inverted? The same for LMA SPD-S.
Section 6
Approval of this flag values are to be made through IANA Expert
Review.
.. note that RFC5226 says: "The required documentation and review
criteria for use by the Designated Expert should be provided
when defining the registry." -- such criteria are not defined.
10. References
.. A number of Informative References are used in a manner in the spec that
they should really be normative. For example, proxy-ARP behaviour leans on
RFC-925; RFC-2473 S 7 and 8 are pulled in in this spec; RFC 4213
considerations on fragmentation are a MUST implement; some IPsec components
as well. The list of informative references needs to be reviewed and some
of these moved to normative.
editorial
---------
3.3.4. IPv4 DHCP Support Mode
A new option, IPv4 DHCP Support Mode Option is defined for using it
in the Proxy Binding Acknowledgment message sent by the local
mobility anchor to the mobile access gateway. This option can be
used for notifying the mobile access gateway, if it should function
as a DHCP Server or a DHCP Relay for the attached mobile node.
.. what if the option is not present? should MAG function in any DHCP capacity?
(A bullet point in S 4.1.3.2 later describes that the default behaviour is
relay. Not sure if this needs clarifying at all, and if yes, where.)
In 3.3.5 (also Section 6)
MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED
... add (": IANA" to the end, I suppose this will also require a number?
In S 4:
o The mobile access gateway can be potentially in a private IPv4
network behind a NAT [RFC-3022] device, with a private IPv4
address configured on its egress interface. But, the local
mobility anchor must not be behind a NAT and must be using a
globally routable IPv4 address. However, both the local mobility
anchor and the mobile access gateway can be in the same private
IPv4 routing domain, i.e., when both are configured with private
IPv4 addresses and with no need for NAT translation between them.
... the "However" makes the previous sentence invalid because clearly LMA is
not required to have a globally routable IPv4 address. Rewording for
precision and more succint representation would be good. What you're saying
that LMA must be deployed so that none of MAGs that need to talk to it need
to go through NAT.