o If there is no IPv4 Home
Address Reply option present in the
received
Proxy Binding Acknowledgement message, the mobile
access
gateway MUST NOT enable IPv4 support
for the mobile node and the
rest of the
considerations from this section can be skipped.
RKo> Why isn't this bullet the first
bullet?
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.
RKo> Does this document assume that the default
encapsulation mode is
*-over-IPv6? Reading the above bullet could lead to
such an
interpretation. Perhaps it is best to capture this at a high level
in
the Introduction, OR move all transport considerations to Section
4.
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.
RKo> Isn't the MAG itself the default router?
The reasons for getting
a default router address in PBA are not
clear..
3.2.4
o
When forwarding the packet through the bi-directional tunnel,
the
encapsulation considerations specified in
section 3.1.3 MUST be
applied. However,
before forwarding the packet, the mobile
access
gateway MUST ensure the source address
in the received packet is
the address
allocated for that mobile node and that there is
an
active binding on the local mobility anchor
for that mobile
node.
RKo> MAG can only
make sure that _it_ has a binding for the MN. It
cannot be sure that LMA has
an active binding - LMA may have rebooted recently
that the MAG is unaware of
(as an example). So, the above MUST for
ensuring that there is an active
binding at LMA, despite the intent,
is not accurate.
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
RKo>
^^^^^^^^^^^^
is it the LMA or the
MAG?
3.4
Any time the
mobile node
performs an
handoff of a physical interface to a
different
mobile access
gateway, using the same interface, the
DHCP
server will always be
able to identify the binding using
the
RKo>
^^^^^^^^^^^^^^
This assumes
that the DHCP server is not in the MAG? Or, the
new MAG somehow gets the DHCP
state.
3.4.1
The
DHCPOFFER
message will also have the subnet
mask option [RFC-2132] and
router option
[RFC-2132], with the values in those options set
to
the mobile node's IPv4 home subnet mask and
default router address
RKo> Here it is assumed that IPv4 HoA returned by
the LMA has subnet
mask (and not prefix-len)
Additionally,
the Server Identifier option will be
included
and with the value in the option set to the
default
router address.
RKo> So, this
default router address is the MAG's address or what is
provided by the LMA in
PBA?
o Any time the mobile node
goes into the DHCP RENEWING state [RFC-
RKo> RENEW or RENEWING?
However, if
the mobile access gateway is unable to complete the Proxy
Mobile
IPv6 signaling or is unable to acquire
the same IPv4 address as
requested by the
mobile node, it will send a DHCPNACK message
[RFC-2131] to the mobile node, as shown in Figure 8-1).
RKo> Add a
sentence that session continuity cannot be provided.
3.4.3
o
When a mobile node sends a DHCPDISCOVER message [RFC-2131],
the
DHCP server or the relay agent co-located
with the mobile access
gateway will trigger
the mobile access gateway to complete the
Proxy Mobile IPv6 signaling. This is the required
interaction
between these two protocols.
RKo> However, all the figures above state that PMIP6 signaling
is
independent of DHCP signaling!
o
The mobile node needs to be identified by the MN-Identifier,
as
specified in Section 6.6 of
[RFC-5213]. This identity should be
associated to the DHCP messages sent by the mobile node.
RKo> What does
the last sentence mean?
4 IPv4
Transport
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.
RKo> Inclusion of
NAT between LMA and MAG needs some justification.
I think the protocol can be
simpler without NAT considerations. (This
does not mean that there is no
support for private IPv4 HoA)
4.1.1
o
The IPv4 NAT translated address of the mobile access gateway.
If
the mobile access gateway is not behind a
NAT [RFC-3022], this
address will be the same
as the address configured on the egress
interface of the mobile access gateway. This address can
be
obtained from the IPv4 header of the
received Proxy Binding Update
message.
However, if the received Proxy Binding Update message
is
not sent as an IPv4 packet, this field in
the Binding Cache entry
MUST be set to
ALL_ZERO value.
RKo> Why is there
a requirement to maintain this address regardless of
the presence of the NAT?
When there is no NAT, you will be maintaining
the same address twice?
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
RKo>
^^^^^^^^^^^^^^^^^^^
The last sentence in the previous
paragraph states how LMA does
NAT Presence Detection. This sentence states
"if it detects NAT". So,
where can I find NAT presence detection
text?
4.1.4.1
o Forwarding Packets Sent by the Mobile Node:
* All the reverse
tunneled packets (IPv4 and IPv6) that the
local
mobility anchor
receives from the mobile access gateway,
after
removing the tunnel
header (i.e., the outer IPv4 header
along
with the UDP and TLV
header, if negotiated) MUST be routed
to
the destination specified
in the inner packet header.
These
routed packets will
have the source address field set to
the
mobile node's home
address.
RKo> Why isn't
there a Figure for this? (Not that I would require it,
but symmetry would be
nice!)
4.2.2.2
o
Forwarding Packets received from the bi-directional tunnel:
o
On receiving a packet from the bi-directional tunnel
established
with the mobile node's local
mobility anchor, the mobile access
gateway
MUST remove the outer header before forwarding the
packet
to the mobile node.
RKo> The above
bullet needs to be "tabbed"