Hello,
I have reviewed the last version of this draft. Below are my comments.
3.1.2.1. Processing Proxy Binding Updates
o If there is an IPv4 Home Address Request option present in the
received Proxy Binding Update message, but if there is no Home
Network Prefix option [RFC-5213] present in the request, the local
mobility anchor MUST NOT reject the request as specified in
Section 5.3.1 of [RFC-5213]. At least one instance of any of
these two options, either the IPv4 Home Address Request option or
the Home Network Prefix option, MUST be present. If there is not
a single instance of any of these two options present in the
request, the local mobility anchor MUST reject the request and
send a Proxy Binding Acknowledgement message with Status field set
to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home
network prefix option) [RFC-5213].
Reword into: If there is an IPv4 Home Address Request option but no Home Network Prefix option [RFC-5213] in the received Proxy Binding Update message, the local mobility anchor MUST NOT reject the request as specified in Section 5.3.1 of [RFC-5213]. At least one instance of any of these two options MUST be present, either the IPv4 Home Address Request option or the Home Network Prefix option, MUST be present. If there is not a single instance of any of these two options present in the request, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with Status field set to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing mobile node's home network prefix option) [RFC-5213].
o If there is at least one instance of Home Network Prefix option
[RFC-5213] present in the received Proxy Binding Update message,
but either if it is known from the mobile node's policy profile
that the mobile node is not authorized for IPv6 service or if IPv6
routing not enabled in the home network, the local mobility anchor
MUST reject the request and send a Proxy Binding Acknowledgement
message with the Status field set to
NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (mobile node not
authorized for IPv6 mobility service).
Reword into: If there is at least one instance of Home Network Prefix option [RFC-5213] present in the received Proxy Binding Update message but it is known from the mobile node's policy profile that the mobile node is not authorized for IPv6 service, or IPv6 routing is not enabled in the home network, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to NOT_AUTHORIZED_FOR_IPV6_MOBILITY_SERVICE (mobile node not authorized for IPv6 mobility service).
o If there is an IPv4 Home Address Request option present in the
received Proxy Binding Update message, but either if it is known
from the mobile node's policy profile that the mobile node is not
authorized for IPv4 service or if IPv4 routing not enabled in the
home network, the local mobility anchor MUST reject the request
and send a Proxy Binding Acknowledgement message with the Status
field set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE (mobile node
not authorized for IPv4 mobility service).
Reword into: If there is an IPv4 Home Address Request option present in the received Proxy Binding Update message but it is known from the mobile node's policy profile that the mobile node is not authorized for IPv4 service, or IPv4 routing is not enabled in the home network, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to NOT_AUTHORIZED_FOR_IPV4_MOBILITY_SERVICE (mobile node not authorized for IPv4 mobility service).
o If there exists a Binding Cache entry that can be associated with
the request and if it is determined that the request is a re-
registration request for extending IPv4 home address mobility
support to the existing IPv6-only mobility session, considerations
from Section 3.1.2.2 MUST be applied with respect to IPv4 support.
Reword into: If there exists a Binding Cache entry that can be associated with the request and if is determined that the request is a re-registration request for extending IPv4 home address mobility support to the existing IPv6-only mobility session, considerations from Section 3.1.2.2 MUST be applied with respect to IPv4 support.
3.1.2.2. Initial Binding Registration (New Mobility Session)
o If there is an IPv4 Home Address Request option with the IPv4
address in the option set to a NON_ZERO value, the local mobility
anchor before accepting the request MUST ensure the address is
topologically anchored on the local mobility anchor and
furthermore the mobile node is authorized to use that address. If
the mobile node is not authorized for that specific address, the
local mobility anchor MUST reject the request and send a Proxy
Binding Acknowledgement message with the Status field set to
NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized
for the requesting IPv4 address). It MUST also include the IPv4
Home Address Reply option in the reply with the status field value
in the option set to 129 (Administratively prohibited).
Reword into: If there is an IPv4 Home Address Request option with the IPv4 address in the option set to a NON_ZERO value, before accepting the request, the local mobility anchor MUST ensure 1) that the address is topologically anchored at the local mobility anchor and 2) that the mobile node is authorized to use that address. If the mobile node is not authorized for that specific address, the local mobility anchor MUST reject the request and send a Proxy Binding Acknowledgement message with the Status field set to NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS (mobile node not authorized for the requesting IPv4 address). It MUST also include the IPv4 Home Address Reply option in the reply with the status field value in the option set to 129 (Administratively prohibited).
Question: What does the LMA do if the address is not topologically anchored at the LMA? What's the status code?
o Upon accepting the request, the local mobility anchor MUST create
a Binding Cache entry for this mobility session. However, if the
request also contains one or more Home Network Prefix options
[RFC-5213], there should still be only one Binding Cache entry
that should be created for this mobility session. The created
Binding Cache entry MUST be used for managing both IPv4 and IPv6
home address bindings. The fields in the Binding Cache entry MUST
be updated with the accepted values for that session.
I found that bullet a bit confusing, especially "however... there should still be". How about: Upon accepting the request, if there exists a Binding Cache entry that can be associated with the Home Network Prefix option(s) [RFC-5213] present in the request
and it is determined that the request is a re-registration request for extending IPv4 home address mobility support to the existing IPv6-only mobility session, the local mobility anchor MUST update the fields in the Binding Cache entry with the accepted values for that session. If there exists no such Binding Cache entry, the local mobility anchor MUST create a new Binding Cache entry for this mobility session. This ensures that a single
Binding Cache entry is used to manage both IPv4 and IPv6 bindings.
o The local mobility anchor MUST establish a bi-directional tunnel
to the mobile access gateway and with the encapsulation mode set
to the negotiated mode for carrying the IPv4 payload traffic.
When using IPv6 transport, the encapsulation mode is IPv4-or-IPv6-
over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6
packet). When using IPv4 transport, the encapsulation mode is as
specified in Section 4.0.
s/and with/with/
s/negotiated mode for carrying/mode negotiated to carry/
o The local mobility anchor MUST create an IPv4 host route (or a
platform specific equivalent function that sets up the forwarding)
for tunneling the packets received for the mobile node's home
address associated with this mobility session.
Reword into: The local mobility anchor MUST create an IPv4 host route towards
the mobile node's home address that points to the tunnel associated with this mobility session.
3.1.2.4. Binding Lifetime Extension (After handoff)
o If there is no Home Network Prefix option(s) [RFC-5213] present in
the request, but if the Binding Cache entry associated [...]
Reword into: If there is no Home Network Prefix option(s) [RFC-5213] present in the request but the Binding Cache entry associated [...]
o The local mobility anchor MUST remove the previously created IPv4
host route (or the forwarding state) and the dynamically created
bi-directional tunnel for carrying the IPv4 payload traffic (if
there are no other mobile nodes for which the tunnel is being
used). This will remove the routing state towards the mobile
access gateway where the mobile node was anchored prior to the
handoff.
Reword into: The local mobility anchor MUST remove the previously created IPv4 host route. If there are no other mobile nodes for which the tunnel is being used, the local mobility anchor MUST remove the dynamically created bi-directional tunnel for carrying the IPv4 payload traffic. This will remove the routing state towards the mobile access gateway where the mobile node was anchored prior to the handoff.
o The local mobility anchor MUST create a bi-directional tunnel to
the mobile access gateway that sent the request (if there is no
existing bi-directional tunnel) and with the encapsulation mode
set to the negotiated mode for carrying the IPv4 payload traffic.
An IPv4 host route for tunneling the packets received for the
mobile node's IPv4 home address MUST also be added.
Reword into: If there is no existing bi-directional tunnel to the mobile access gateway that sent the request, the local mobility anchor MUST create one with the encapsulation mode set to the negotiated mode for carrying the IPv4 payload traffic. An IPv4 host route for tunneling the packets received for the mobile node's IPv4 home address MUST also be added.
3.1.2.5. Binding De-Registration
All the considerations from Section 5.3.5 of [RFC-5213] MUST be
applied. Additionally, for removing the IPv4 state as part of the
Binding Cache entry deletion, the IPv4 host route and the dynamically
created bi-directional tunnel for carrying the IPv4 payload traffic
(if there are no other mobile nodes for which the tunnel is being
used) MUST be removed. [...]
Reword into: All the considerations from Section 5.3.5 of [RFC-5213] MUST be applied. Additionally, for removing the IPv4 state as part of the Binding Cache entry deletion, the IPv4 host route MUST be removed, and the dynamically created bi-directional tunnel for carrying the IPv4 payload traffic MUST be removed if there are no other mobile nodes for which the tunnel is being used. [...]
3.1.2.6. Constructing the Proxy Binding Acknowledgement Message
o Section 5.3.6 of [RFC-5213] requires the local mobility anchor to
include at least one instance of Home Network Prefix option [RFC-
5213] in the Proxy Binding Acknowledgement message that it sends
to the mobile access gateway. However, if the received Proxy
Binding Update message has only the IPv4 Home Address Request
option and did not contain the Home Network Prefix option(s), then
the local mobility anchor MUST NOT include any Home Network Prefix
option(s) in the reply. However, there MUST be at least one
instance of either the Home Network Prefix option [RFC-5213] or
the IPv4 Home Address Reply option present in the Proxy Binding
Acknowledgement message.
There's two 'however' above. Suggest to reword into: Section 5.3.6 of [RFC-5213] requires the local mobility anchor to include at least one instance of Home Network Prefix option [RFC-5213] in the Proxy Binding Acknowledgement message that it sends to the mobile access gateway. However, if the received Proxy Binding Update message has the IPv4 Home Address Request option and does not contain the Home Network Prefix option(s), then the local mobility anchor MUST NOT include any Home Network Prefix options in the reply. There MUST be at least one instance of either the Home Network Prefix option [RFC-5213] or the IPv4 Home Address Reply option present in the Proxy Binding Acknowledgement message.
o The IPv4 Home Address Reply option MUST be present in the Proxy
Binding Acknowledgement message.
Insert: "as per the requirements below" before the period.
o The IPv4 Default-Router Address option MUST be present, if the
Status field value in the Proxy Binding Acknowledgement message is
set to 0 (Proxy Binding Update Accepted). Otherwise, the option
MUST NOT be present. If the option is present, the default router
address in the option MUST be set to the mobile node's default
router address.
Shouldn't the IPv4 Default-Router Address option present only if the IPv4 Home Address Reply option is present as well?
3.1.2.7. Binding Cache Entry Lookup Considerations
The Binding Cache entry lookup considerations specified in section
5.4.1.1 of [RFC-5213] uses the Home Network Prefix option [RFC-5213]
as the key parameter for identifying the Binding Cache entry.
However, when there is not a single Home Network Prefix option with a
NON_ZERO value present in the request, but if there is an IPv4 Home
Address option with a NON_ZERO value present in the request, then the
following considerations MUST be applied.
Reword the second sentence into: "However, when the request contains an IPv4 Home Address option but no Home Network Prefix option with a NON_ZERO value, then the following considerations MUST be applied."
o These rules specified in section 5.4.1.1 of [RFC-5213], assume the
presence of one or more IPv6 home network prefixes in the received
request and also in the Binding Cache entry. But, when using the
IPv4 home address as the search key, these considerations MUST
always assume just one single IPv4 home address, both in the
request and also in the Binding Cache entry.
s/These rules/The rules/
Reword into "The rules specified in section 5.4.1.1 of [RFC-5213] assume the presence of one or more IPv6 home network prefixes in both the received request and the Binding Cache entry. However, when using the IPv4 home address as the search key, these considerations MUST assume that a single IPv4 home address is present in both the received request and the Binding Cache entry."
3.1.3. Routing Considerations for the Local Mobility Anchor
Intercepting Packets Sent to the Mobile Node's IPv4 home address:
o When the local mobility anchor is serving a mobile node, it MUST
advertise a connected route in to the Routing Infrastructure for
the mobile node's IPv4 home address or for its home subnet, in
order to receive packets that are sent to the mobile node's IPv4
home address. This essentially enables IPv4 routers in that
network to detect the local mobility anchor as the last-hop router
for that subnet.
s/in to/into/
o All the reverse tunneled packets that the local mobility anchor
receives from the mobile access gateway, after removing the tunnel
header MUST be routed to the destination specified in the inner
IPv4 packet header. These routed packets will have the source
address field set to the mobile node's IPv4 home address.
Reword into: "All the reverse tunneled packets that the local mobility anchor receives from the mobile access gateway MUST be forwarded to the destination specified in the inner IPv4 packet header after removal of the outer tunnel header. These packets will have the source address field set to the mobile node's IPv4 home address."
3.2.3.1. Mobile Node Attachment and Initial Binding Registration
* The mobile access gateway MAY also ask the local mobility
anchor for dynamic IPv4 home address allocation. It can
include exactly one instance of the IPv4 Home Address option
with the IPv4 home address and the prefix length fields in the
option set to ALL_ZERO value. Furthermore, the (P) flag in the
option MUST be set to 0. This essentially serves as a request
to the local mobility anchor for the IPv4 home address
allocation.
Removes "essentially", or list what this does besides requesting IPv4 address allocation.
3.2.3.2. Receiving Proxy Binding Acknowledgement
o If the received Proxy Binding Acknowledgement message has the
Status field value set to 0 (Proxy Binding Update accepted), the
mobile access gateway MUST update a Binding Update List entry for
that mobile node. The entry MUST be updated with the assigned
IPv4 home address and other accepted registration values
o If the received Proxy Binding Acknowledgement message has the
Status field value set to 0 (Proxy Binding Update accepted) and
has the IPv4 Home Address Reply option set to a value that
indicates that the request was accepted by the local mobility
anchor, the mobile access gateway MUST establish a bi-directional
tunnel to the local mobility anchor (if there is no existing bi-
directional tunnel to that local mobility anchor) and with the
encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or IPv6
packet carried as a payload of an IPv6 packet). Considerations
from Section 5.6.1 of [RFC-5213] MUST be applied for managing the
dynamically created bi-directional tunnel. However, when using
IPv4 transport, the encapsulation mode MUST be set to the
negotiated encapsulation mode, as specified in Section 4 of this
specification.
o The mobile access gateway MUST set up the route for forwarding the
IPv4 packets received from the mobile node (using its IPv4 home
address) through the bi-directional tunnel set up for that mobile
node.
o The default router address MUST be obtained from the IPv4 Default-
Router Address option present in the received Proxy Binding
Acknowledgement message. The mobile access gateway SHOULD
configure this address on its interface and respond to any ARP
requests sent by the mobile node for resolving the hardware
address of the default router. 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 mobile access
gateway MAY also use the default router address as the source
address for any datagrams sent to the mobile node and originated
by the mobile access gateway itself. It MUST also use this
address in the DHCP Router option [RFC-2132] in the DHCP messages.
Why are the four bullets above separate? In particular, can the first bullet happens but not the second? It seems to me they should happen together and should be merged. Also, the part on setting up the bidirectional tunnel is using parenthesis while their content is not parenthetical. I suggest to reword "the mobile access gateway MUST establish a bi-directional tunnel to the local mobility anchor (if there is no existing bi-directional tunnel to that local mobility anchor) and with the encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6 packet)" into "the mobile access gateway MUST establish a bi-directional tunnel to the local mobility anchor with the encapsulation mode set to IPv4-or-IPv6-over-IPv6 (IPv4 or IPv6 packet carried as a payload of an IPv6 packet) if there is no existing bi-directional tunnel to that local mobility anchor"
3.2.4. Routing Considerations for the Mobile Access Gateway
o The mobile access gateway SHOULD use Proxy ARP [RFC-925] to reply
to ARP Requests that it receives from the mobile node seeking
address resolutions for the destinations on the mobile node's home
subnet. 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. However, on certain types of links,
the mobile node does not use ARP for address resolutions, instead
it forwards all the packets to the mobile access gateway. On such
types of links, the mobile access gateway is not required to
support Proxy ARP function. At the same time, implementations not
supporting the Proxy ARP function on links where the mobile node
uses ARP for seeking address resolutions for the destinations on
the mobile node's home subnet will result in communication
failure.
Hmm. I had completely overlooked the proxy ARP function in earlier revisions of this draft... this is introducing multilink subnet issues to the IPv4 support for PMIPv6. Do we want to call them out explicitly and reference RFC 4903?
3.4. Supporting DHCP-Based Address Configuration
* If the mobile node attaches to the Proxy Mobile IPv6 domain
through multiple physical interfaces, the DHCP server will
uniquely identify each of those interfaces and will perform
address assignment. The DHCP server will identify the
interface as specified in RFC 2131. The mobile node SHOULD
generate and use the "Client-identifier" for each physical
interface according to [RFC-4361]. [...]
This is placing a requirement on a mobile node. Since our charter had the "no host change" clause, are we sure that this is something we want to do? In other words, will the protocol break without RFC 4361 styled client IDs?
* If the mobile node is capable of performing handoff between
interfaces, as per [RFC-5213], a "Client-identifier" value MUST
be used for the attachment point that is not tied to any of the
physical interfaces. The identifier MUST be generated
according to [RFC-4361], which guarantees that the identifier
is stable and unique across all "Client-identifier" values in
use in the Proxy Mobile IPv6 domain.
That one also seems problematic in light of the "no host change" clause. I thought inter-access handoffs were out of scope...
4. IPv4 Transport Support
o The local mobility anchor and the mobile access gateway are both
configured and reachable using an IPv4 address. Additionally,
both entities are also IPv6 enabled and have configured IPv6
addresses on their interfaces, as specified in [RFC-5213], but are
reachable only over an IPv4 transport network.
How about 's/but are reachable only/ but can only communicate together/' ?
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.
Reword into: "The mobile access gateway can potentially be in a private IPv4 network behind a NAT [RFC-3022] device and be assigned with a private IPv4 address [RFC-1918] on the interface towards the LMA. In that case, the local mobility anchor must not be behind a NAT and must be using a global unicast IPv4 address. However, both the local mobility anchor and the mobile access gateway can be in the same private IPv4 routing domain and both be assigned with private IPv4 addresses [RFC-1918] as long as there's no NAT box between them.
o The mobile node can be an IPv6, IPv4 or a dual IPv4/IPv6 node and
the IPv4 transport support specified in this section is agnostic
to the type of address mobility enabled for that mobile node.
s/IPv6, IPv4 or a dual IPv4/IPv6 node/IPv6, IPv4, or a dual stack IPv4/IPv6 node/
4.1.3.1. Processing Proxy Binding Updates
o Upon accepting the request, the local mobility anchor MUST set up
an IPv4 bi-directional tunnel to the mobile access gateway. The
tunnel endpoint addresses are IPv4-LMAA and the IPv4-Proxy-CoA.
The encapsulation mode MUST be determined by applying the
following considerations:
I thought a tunnel is created only in case there's not one already. The text above contradicts that.
o The local mobility anchor MUST send the Proxy Binding
Acknowledgement message with the Status field value set to (0)
(Proxy Binding Update Accepted). The message MUST be constructed
as specified in Section 4.1.3.2.
I'm not sure about this. It reads like the LMA always sends a PBAck with status field set to success. I don't think that is really the case...
4.1.3.2. Constructing the Proxy Binding Acknowledgement Message
o The Proxy Binding Acknowledgement message MUST be encapsulated in
an IPv4 packet. However, if the received Proxy Binding Update
message was sent encapsulated in an IPv4-UDP packet, then the
Proxy Binding Acknowledgement message MUST be encapsulated in the
UDP header of an IPv4 packet.
How about "The Proxy Binding Acknowledgement message MUST be encapsulated as the Binding Update message triggering it, i.e., in an IPv4 packet, or an IPv4-UDP packet."
o If the mobile access gateway and the local mobility anchor are
using globally routable IPv4 addresses and if there is a security
association that is based on IPv4 addresses, then the encapsulated
IPv4 packet (containing the IPv6 Proxy Binding Acknowledgement)
MUST be protected using IPsec ESP [RFC-4301] mode. There is no
need to apply IPsec ESP header to the IPv6 packet. In all other
cases, the Proxy Binding Acknowledgement message MUST be protected
using IPsec prior to the IPv4 or IPv4-UDP encapsulation.
In "using IPsec ESP [RFC-4301] mode", are we missing "tunnel" or "transport" before "mode"? Also it seems the reference to 4301 should come at the end of the sentence... If the last sentence means IPsec is applied to the inner IPv6 header, maybe it's better to say so, as well as to specify the mode, presumably transport.
4.2.2. Signaling considerations
o If the received Proxy Binding Acknowledgement message is
encapsulated in IPv4 or IPv4 UDP packet, the message MUST be
authenticated after removing the outer IPv4 or IPv4-UDP header.
Considerations from Section 4 of [RFC-5213] MUST be applied for
authenticating and authorizing the message.
The paragraph above seems to be in contradiction with the one I quoted above which said in some situations there can be an IPv4 SA. I guess this has to be corrected. Also s/IPv4 UDP/IPv4-UDP"?
o If the Status field indicates Success, the mobile access gateway
MUST setup a bi-directional tunnel to the local mobility anchor.
o Upon accepting the request, the mobile access gateway MUST set up
an IPv4 bi-directional tunnel to the local mobility anchor. The
tunnel endpoint addresses are IPv4-Proxy-CoA and the IPv4-LMAA.
The encapsulation mode MUST be determined from the below
considerations.
These two are redundant aren't they? Also, the tunnel only needs to be setup when it's not present already. That should be covered.
o The encapsulation mode for the bi-directional tunnel MUST be set
to IPv4. However, if the value of the configuration variable,
UseIPv4UDPEncapForSignalingMessages, is set to (1), then the
following considerations MUST be applied.
* If there is a NAT Detection option [RFC-5555] in the received
Proxy Binding Acknowledgement message and if the value of the
configuration flag, UseIPv4UDPEncapForSignalingMessages, is set
to value of (1), then the encapsulation mode for the tunnel
MUST be set to IPv4-UDP. Otherwise the encapsulation mode MUST
be set to IPv4.
The "if UseIPv4UDPEncapForSignalingMessages is set to (1)" is redundant in the two paragraphs above...
4.2.2.1. Constructing the Proxy Binding Update Message
o The Proxy Binding Update message MUST be protected using IPsec ESP
[RFC-4301], as specified in [RFC-5213]. The protection MUST be
applied on the IPv6 packet of the Proxy Binding Update message,
prior to the IPv4 encapsulation.
Same as earlier: somewhere it is said that an IPv4 SA can be applied, which isn't covered here.
4.3. IPsec Considerations
4.3.1. PBU and PBA
The following section describes how IPsec is used for protecting the
signaling messages and data packets between the local mobility anchor
and mobile access gateway when using IPv4 transport.
The following are the SPD example entries to protect PBU and PBA on
the local mobility anchor and mobile access gateway.
MAG SPD-S:
- IF local_address = Proxy-CoA_1 &
remote_address = LMAA_1 & proto = MH &
local_mh_type = PBU & remote_mh_type = PBAck
Then use SA ESP transport mode
LMA SPD-S:
- IF local_address = LMAA_1 &
remote_address = Proxy-CoA_1 & proto = MH &
local_mh_type = PBAck & remote_mh_type = PBU
Then use SA ESP transport mode
Same here. There's no example for the IPv4 IPsec SA....
MAG's IPsec module
:
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: ESP header in transport mode
: Mobility header
: PBU (p flag)
: Home Network Prefix option
: IPv4 Home Address Request option
: IPv4 Care-of Address option
: : * After adding the ESP header, the PBU is returned to the PMIP
: module and is encapsulated into the UDP and IPv4 headers.
: This requires a Proxy Mobile IPv6 specific IPsec implementation,
: which knows that the packet needs to be passed back to the PMIP
: module, instead of sending it out via the normal forwarding
I'm not sure about this statement. If the IPv4-UDP tunnel appears as a tunnel interface, and a routing table entry makes the destination IPv6 LMA address available at the other end of that tunnel things might work just well with a native or bump in the stack IPsec implementation.
LMA (received at DSMIPv6 port)
:
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: ESP header in transport mode
: Mobility header
: PBU (p flag)
: Home Network Prefix option
: IPv4 Home Address Request option
: IPv4 Care-of Address option
:
: *In addition, IPv4-Proxy-CoA and the sport (Z) needs to
: be passed along with the packet to ensure correct processing.
\:/
LMA's IPsec module
:
: IPv6 header (src=Proxy-CoA, dst=LMAA)
: Mobility header
: PBU (p flag)
: Home Network Prefix option
: IPv4 Home Address Request option
: IPv4 Care-of Address option
:
: *In addition, IPv4-Proxy-CoA and the sport (Z) need to
: be passed with the packet to ensure correct processing.
\:/
LMA's PMIP module
Here, I am not sure I agree with the two (*) above that says the IPv4-Proxy-CoA and the sport (Z) have to be passed along with the packet. The LMA PMIP module could store that information when the packet is received at the DSMIPv6 port and match it back to the decapsulated packet after IPsec processing, no?
The same comments applies to sending/receiving the PBA so I'm not going to repeat myself.
--julien
-----Original Message-----
From: netlmm-bounces at ietf.org [mailto:netlmm-bounces at ietf.org] On
Behalf Of Sri Gundavelli
Sent: Saturday, September 12, 2009 8:17 AM
To: netlmm at ietf.org
Subject: [netlmm] New Version Notification for draft-ietf-netlmm-pmip6-
ipv4-support-17 (fwd)
This resolves all the IESG comments.
- Added 4361 ref, on DHCP client identifiers and some nits
that got in the prev version. Minor textual change on
how RFC-2131 identies the DHCP bindings, as suggested
by Ralph.
- Addresses Pekka savola's comments.
Regards
Sri
---------- Forwarded message ----------
Date: Sat, 12 Sep 2009 08:09:13 -0700 (PDT)
From: IETF I-D Submission Tool <idsubmission at ietf.org>
To: sgundave at cisco.com
Cc: ryuji at us.toyota-itc.com
Subject: New Version Notification for
draft-ietf-netlmm-pmip6-ipv4-support-17
A new version of I-D, draft-ietf-netlmm-pmip6-ipv4-support-17.txt has
been successfuly submitted by Sri Gundavelli and posted to the IETF
repository.
Filename: draft-ietf-netlmm-pmip6-ipv4-support
Revision: 17
Title: IPv4 Support for Proxy Mobile IPv6
Creation_date: 2009-09-12
WG ID: netlmm
Number_of_pages: 62
Abstract:
This document specifies extensions to Proxy Mobile IPv6 protocol for
adding IPv4 protocol support. The scope of IPv4 protocol support is
two-fold: 1) enable IPv4 home address mobility support to the mobile
node. 2) allowing the mobility entities in the Proxy Mobile IPv6
domain to exchange signaling messages over an IPv4 transport network.
The IETF Secretariat.
_______________________________________________
netlmm mailing list
netlmm at ietf.org
https://www.ietf.org/mailman/listinfo/netlmm