IPv4 Support for Proxy Mobile IPv6
draft-ietf-netlmm-pmip6-ipv4-support-18
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
18 | (System) | post-migration administrative database adjustment to the Yes position for Jari Arkko |
2012-08-22
|
18 | (System) | post-migration administrative database adjustment to the No Objection position for Ralph Droms |
2012-08-22
|
18 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
2010-04-12
|
18 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2010-04-12
|
18 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2010-04-12
|
18 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2010-03-26
|
18 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2010-03-15
|
18 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2010-03-15
|
18 | (System) | IANA Action state changed to In Progress |
2010-03-15
|
18 | Amy Vezza | IESG state changed to Approved-announcement sent |
2010-03-15
|
18 | Amy Vezza | IESG has approved the document |
2010-03-15
|
18 | Amy Vezza | Closed "Approve" ballot |
2010-03-13
|
18 | Jari Arkko | State Changes to Approved-announcement to be sent from IESG Evaluation::External Party by Jari Arkko |
2010-03-12
|
18 | Jari Arkko | Michelle Cotton at IANA is checking the IANA issue. |
2010-03-12
|
18 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Yes from Discuss by Jari Arkko |
2010-02-25
|
18 | Jari Arkko | State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko |
2010-02-25
|
18 | Jari Arkko | Ready to be approved, Pasi, Jari, Ralph are OK with contents. Asking Ron if he wants to review. |
2010-02-13
|
18 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2010-02-13
|
18 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-18.txt |
2010-02-05
|
18 | Jari Arkko | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::External Party by Jari Arkko |
2010-02-05
|
18 | Jari Arkko | Consensus call concluded, document needs to implement the revision. |
2009-11-20
|
18 | Jari Arkko | State Changes to IESG Evaluation::External Party from IESG Evaluation::AD Followup by Jari Arkko |
2009-11-20
|
18 | Jari Arkko | Waiting for Pasi and Jonne for their suggested alternate text. |
2009-09-16
|
18 | Ralph Droms | [Ballot Position Update] Position for Ralph Droms has been changed to No Objection from Discuss by Ralph Droms |
2009-09-12
|
17 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-17.txt |
2009-09-11
|
18 | Ralph Droms | [Ballot comment] |
2009-09-11
|
18 | Ralph Droms | [Ballot discuss] rev -16 of this doc is much improved. Although I have not cleared all of my DISCUSS issues, I think the doc is … [Ballot discuss] rev -16 of this doc is much improved. Although I have not cleared all of my DISCUSS issues, I think the doc is close to publication. BTW, a couple of the remaining DISCUSS issues are the result of the wording of my previous DISCUSSes, and I'm sorry for the confusion... My first DISCUSS was, on reflection, really two different issues. The second (which I won't repeat here) has been resolved. The first is still issue still exists in -16. The document is not clear about whether assigning the IPv4 address used by the MN as its default router MUST or MAY be assigned to the MAG interface facing the MN. Section 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. This fixed address can be potentially an IPv4 private address [RFC-1918] that can be used for the DHCP protocol communication on any of the access links. This address will be used as the server identifier in the DHCP messages. Is this configuration of addresses a protocol requirement that needs some normative language, and that needs to be reflected elsewhere in the document? And, to be picky, a DHCP server or relay agent isn't configured with an IPv4 address, per se. I know what is meant - DHCP uses IPv4 addresses as identifiers; e.g., as a "Server identifier" and in the 'giaddr' field - so the idea is to ensure that the same identifier is used throughout the domain to provide a consistent environement for the host. For example, in section 3.4.1: o If a fixed address such as the IPv4 default router address of the mobile node is used as the DHCP server Id on any of the links in that Proxy Mobile IPv6 domain... Either the fixed address is required, as specified in the earlier bullet from section 3.4, or, if it's not required, and the "If" clause in this text is false, how does DHCP work? --- I understand, now, that the use of point-to-point links obviate the need for explicit assignment of an IPv4 address to the MAG interface on the link with the MN. The point-to-point links are also used to allow for conditional implementation of ARP and proxy ARP; e.g., from the third bullet on page 21: 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. and the last bullet in section 3.2.4: 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. [...] 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. The mobile node can be configured to use the point-to- point link for sending all IP packets. Is it the case that a MN MUST be configured to forward all IP traffic on the point-to-point link without using ARP? Or, is it possible that an MN using a point-to-point link might still use ARP? Unless there is a guarantee that no MN will ever send ARP I think there will be interoperability issues with "SHOULD [...] respond to any ARP requests" and "SHOULD use proxy ARP". --- My suggestions for corrections to the text describing the use of the DHCP "client identifier" were unclear. So, let me see if I can get it right here: o A DHCP server identifies a DHCP interface from the contents of the DHCP "Client-identifier" option [RFC-2132], if present, or from the client hardware address (chaddr), as specified in [RFC-2131]. Note that the name "Client-identifier" is a misnomer as it actually identifies an interface and not the client. The DHCP server uses this identity to identify the interface for which the address is assigned. A mobile node in a Proxy Mobile IPv6 domain, can attach to the network through multiple interfaces and can obtain address configuration for each of its interfaces. Additionally, it may perform handoffs between its interfaces. Following are the related considerations with respect to the identification presented to the DHCP server. * 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]. 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 presented identifier. The presented identifier (either the "Client-identifier" or the hardware address) will remain as the primary key for each binding, just as how they are unique in a Binding Cache entry. * 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. Note that I've specified the use of RFC 4361 for generation of "Client-identifier" values. This style of "Client-identifier" will produce stable identifiers for the virtual interfaces with vanishingly small probability of identifier clashes. |
2009-09-10
|
16 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-16.txt |
2009-09-08
|
18 | Ralph Droms | [Ballot comment] Updated for rev -15. In figure 1, doesn't either MAG1 need a Proxy-CoA address or LMA2 need an IPv4-LMAA, so that MAG1 and … [Ballot comment] Updated for rev -15. In figure 1, doesn't either MAG1 need a Proxy-CoA address or LMA2 need an IPv4-LMAA, so that MAG1 and LMA2 have a shared version of IP over which they can communicate? --- In section 2.2: Mobile Node's IPv4 Home Address (IPv4-MN-HoA) The IPv4 home address assigned to the mobile node's attached interface. This address is topologically anchored at the local mobility anchor. Which local mobility anchor is the address anchored at? --- In section 3: The IPv4 home address mobility support essentially enables a mobile node in a Proxy Mobile IPv6 domain to obtain IPv4 home address configuration for its attached interface and be able to retain that address configuration even after changing its point of attachment in that Proxy Mobile IPv6 domain. This section describes the protocol operation and the required extensions to Proxy Mobile IPv6 protocol for extending IPv4 home address mobility support. This paragraph talks about the MN as having a single IPv4 interface and associated address configuration, while the last paragraph describes operation if there are multiple interfaces. I think it would be more consistent to talk about interfaces and allow for a MN to have multiple interfaces. --- In section 3.1.2.1, there is discussion of a policy profile in which the MN may or may not be authorized for IPv6 service. Is there a similar authorization for IPv4 service in that profile? --- Also in section 3.1.2.1, do the considerations for re-registration and de-registration need to be extended to consider the MN's IPv4-Proxy-CoA? o If there exists a Binding Cache entry that can be associated with the request, the local mobility anchor MUST apply considerations from Section 5.3.1 of [RFC-5213], (point 13), to determine if the request is re-registration or a de-registration request. If the request is a re-registration request, considerations from Section 3.1.2.3 MUST be applied and if it is a de-registration request, considerations from Section 3.1.2.4 MUST be applied. And, in the previous paragraph, are the section numbers correct? --- In section 3.2.3.1, are the two sub-bullets under "The IPv4 Home Address Request option MUST be present in the Proxy Binding Update message" mutually exclusive alternatives? --- The first two bullets in the list in section 3.2.3.2 seem to be contradictory, in that they specify different behaviors in the MAG in response to receipt of the same Proxy Binding Ack message from the LMA. --- Is there some difference in the predicate conditions in the last two bullets on page 20? In more detail, is it possible for the Proxy Binding Ack message to have status Accepted while the IPv4 Home Address option has a failure status? --- These two bullets in section 3.2.4 may be contradictory; the first seems to allow local routing while the second requires traffic to be forwarded to the LMA: o Considerations from Section 6.10.3 of [RFC-5213] MUST be applied with respect the local routing and on the use of EnableMAGLocalRouting flag. o On receiving a packet from a mobile node connected to its access link, the packet MUST be forwarded to the local mobility anchor through the bi-directional tunnel established with the local mobility anchor. |
2009-09-08
|
18 | Ralph Droms | [Ballot discuss] I've updated my DISCUSS based on rev -15 of the doc. I'm still left with a fundamental question about the deployment requirements for … [Ballot discuss] I've updated my DISCUSS based on rev -15 of the doc. I'm still left with a fundamental question about the deployment requirements for IPv4 address assignment in MAGs. From Section 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. This fixed address can be potentially an IPv4 private address [RFC-1918] that can be used for the DHCP protocol communication on any of the access links. This address will be used as the server identifier in the DHCP messages. If I understand this paragraph correctly, in the case: o DHCP relay agent co-located with the mobile access gateway. the relay agent uses the MN's default router address, and in this case: o DHCP server co-located in the mobile access gateway. the server uses either the MN's default router address or an IPv4 address that is fixed across all MNs and MAGs. In the latter case, each MAG knows to forward IPv4 traffic to that single fixed address to the DHCP server in the MAG. Is this configuration of addresses a protocol requirement that needs some normative language, and that needs to be reflected elsewhere in the document? For example, in section 3.4.1: o If a fixed address such as the IPv4 default router address of the mobile node is used as the DHCP server Id on any of the links in that Proxy Mobile IPv6 domain... Either the fixed address is required, as specified in the earlier bullet from section 3.4, or, if it's not required, and the "If" clause in this text is false, how does DHCP work? Expanding on this question, this text in section 3.2.3.2 uses "MAY": 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 MAY 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. It MAY also use this address as the source address for any datagrams sent to the mobile node and originated by the mobile access gateway itself. It MAY also use this address in the DHCP Router option [RFC-2132] in the DHCP messages. I guess if I read the last sentence carefully, the MAY could be correct because the MAG will use the address in the DHCP Router option only if the MAG is not acting as a DHCP server and using a single common IPv4 address for all MNs. However, consistent with the requirements in section 3.4, shouldn't the use of the default router address be a MUST requirement? --- This sentence from section 3.1.2.7 is not parseable: However, when there are no Home Network Prefix options with a NON_ZERO value present in the request a single Home Network Prefix option with NON_ZERO value present in the request, but if there an IPv4 Home Address option with a NON_ZERO value present in the request, the following considerations MUST be applied. --- In section 3.2.4, under what circumstances would the MAG not implement proxy ARP for the MN's home subnet and what are the consequences: o The mobile access gateway MAY 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 can examine the target IP address of the Request, and if this IP address matches the mobile node's IPv4 home subnet, it MAY transmit a Proxy ARP Reply. --- From section 3.4, this text needs to be more careful about describing the "client identifier" (which is admittedly misnamed, as it is actually a fixed "interface identifier") identifies an interface (but not a host) to a DHCP server. My apologies to the authors, as I had previously agreed to this text, which I now see needs a little tweaking. o A DHCP server identifies a DHCP client from the client identifier, s/client/interface/ if present, or from the client hardware address (chaddr), as specified in [RFC-2131]. It uses this identity for identifying the client and its interface for which the address is assigned. A s/client and its interface/the interface/ mobile node in a Proxy Mobile IPv6 domain, can attach to the network through multiple interfaces and can obtain address configuration for each of its interfaces. Additionally, it may perform handoffs between its interfaces. Following are the related considerations with respect to the identification presented to the DHCP server. * If the mobile node attaches to the Proxy Mobile IPv6 domain through multiple interfaces, the DHCP server will uniquely identify each of those interfaces and will perform address assignment. The DHCP server will identify the client as s/client/interface/ specified in [RFC-2131]. If the client identifier is present, that will be used for identifying the mobile node, otherwise s/mobile node/mobile node interface/ the client hardware address will be used. Anytime the mobile node changes its point of attachment in the network and What is "point of attachment"? performs an handoff to a different mobile access gateway, using the same interface, the DHCP server will always be able to identify the binding using the presented identifier, the client identifier or the hardware address. The client identifier or the hardware address will remain as the primary key for each binding, just as how they are unique in a Binding Cache entry. When the mobile node performs a handoff and moves an interface to a different MAG, the interface MUST continue to use the same identifier (either client identifier or hardware address) so that the DHCP server will associate the interface with the existing DHCP address binding. Does "just as how they [client identifier or hardware address] are unique in a Binding Cache entry" imply that the DHCP identifier is in the Binding Cache? Does it need to be? * However, if the mobile node is capable of performing handoff between interfaces, as per [RFC-5213], the client 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 ... so that the DHCP server will identify the session with the existing DHCP address binding for that session and maintian the same IPv4 address for the session. This identifier in some implementations can be the identifier associated to a virtual interface, that is abstracting the physical interfaces. --- Section 3.4: o Any time the mobile node goes into the DHCP RENEWING state [RFC- 2131], it simply unicasts the DHCPREQUEST message including the assigned IPv4 home address in the 'requested IP address' option. The DHCPREQUEST is sent to the address specified in 'server identifier' field of the previously received DHCPOFFER and DHCPACK s/'server identifier' field/Server Identifier option/ messages. |
2009-08-27
|
18 | Pasi Eronen | [Ballot comment] The base Proxy Mobile IPv6 spec (RFC 5213) uses IPsec in a very simple way: it requires no Mobile IP specific … [Ballot comment] The base Proxy Mobile IPv6 spec (RFC 5213) uses IPsec in a very simple way: it requires no Mobile IP specific changes to IPsec, and it's even possible to use a "bump-in-the-wire" implementation, such as a separate IPsec gateway sitting next to the MAG and LMA. The IPv4 transport support introduced in this document completely changes the situation by requiring Mobile IP specific changes to IPsec, and preventing the use of separate gateway/"bump-in-the-wire" implementation. With these changes, I do not think IPsec is anymore a reasonable solution for securing PMIP. However, it is not realistic to ask this draft to fix the situation; thus, I am balloting "abstain". |
2009-08-27
|
18 | Pasi Eronen | [Ballot discuss] |
2009-08-27
|
18 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to Abstain from Discuss by Pasi Eronen |
2009-08-23
|
18 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-08-23
|
15 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-15.txt |
2009-08-18
|
18 | Ralph Droms | [Ballot comment] Updated for rev -14. Is there any impact of lease lengths on the use of DHCP address assignment? If so, guidance would be … [Ballot comment] Updated for rev -14. Is there any impact of lease lengths on the use of DHCP address assignment? If so, guidance would be helpful; if not, explicitly mentioning that lease length doesn't matter would be helpful. |
2009-08-18
|
18 | Ralph Droms | [Ballot discuss] I've updated my DISCUSS based on rev -14 of the doc. Some, but not all, of my issues have been addressed. I've added … [Ballot discuss] I've updated my DISCUSS based on rev -14 of the doc. Some, but not all, of my issues have been addressed. I've added comments explaining my responses to the changes in the doc. In addition, I have some new issues with text added to section 3.4.3. > From conversations with the authors, a "handoff" is a change of > network attachment that is not reported to layer 3 as a loss of link > connection. The differentiation between handoff and a change of > network attachment that is reported to L3 is important in section 3.4, > as a DHCP message exchange is triggered by network reconnection > reported to L3. > > The use of 'client identifier' and 'chaddr' in this text from section > 3.4 differs from the use of those fields in DHCP servers. > > o A DHCP server identifies the DHCP client and its interface for > which the address is assigned from the client identifier and the > client hardware address (chaddr) [RFC-2131] fields respectively. > A mobile node in a Proxy Mobile IPv6 domain, can attach to the > network through multiple interfaces and additionally may perform > handoffs between its interfaces. Following are the related > considerations: > > The first issue is that DHCPv4 does not have any concept of multiple > interfaces attached to a single host computer. Each address > assignment - called a 'binding' (this term should be cited as defined > in RFC 2131, to clarify and make distinct from other bindings in this > document) - is regarded as independent, even if the addresses are > assigned to interfaces on the same host. The referenced text has been revised in -13 and is now OK. > The second issue is that the DHCP server uses the client identifier > (if it's available) or the chaddr to identify the entity to which an > address is assigned. Therefore, it's not possible to assign addresses > as suggested in the following text: > > * If the mobile node attaches to the Proxy Mobile IPv6 domain > through multiple interfaces, the DHCP server will uniquely > identify each of those interfaces from the client hardware > address and will perform address assignment. As the mobile > node changes its point of attachment in the network and > performs an handoff to a different mobile access gateway, using > the same interface, the DHCP server will always be able to > identify the binding using the presented client hardware > address. The client hardware address and client identifier > will remain as the primary keys for each binding, just as how > they are unique in a Binding Cache entry. > > Specifically, the client identifier is the identifier for a binding, > so there is no concept of using both the client identifier and > hardware address as primary keys. > > So, I think I understand what's going on in this first sub-bullet > (although the first sentence seems out of place). The preceding bullet appears to be unchanged in -14, and my earlier comments still apply. This text needs to be fixed by specifying that the DHCPv4 identifier - client identifier, if supplied, or hardware address - is used by the DHCPv4 server to identify the interface. > The second sub-bullet, if I understand it correctly, is also easy to > fix: > > * However, if the mobile node is capable of performing handoff > between interfaces, as per [RFC-5213], the client hardware > address 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. > > I'm guessing that the idea here is to move the IPv4 address from > interface A to interface B when the handoff happens. If I've got that > right, then the client needs to use the same client identifier for any > subsequent DHCP message exchanges on interface B. > > I'm still not clear about how the use of multiple simultaneous > interfaces fits into the model. The preceding bullet also appears to be unchanged in -14, and my earlier comments still apply. Here, too, what is needed is to replace "hardware address" with some way of describing the DHCP identifier. > Section 3.4.1 needs some additional detail to describe what happens > when the steps 2-4 in Figure 5 occur before step 1. When the DHCP > server receives the DHCPDISCOVER message, it needs to check to see if > the tunnel is already set up. > > If the tunnel setup is not complete before the DHCP client retransmits > the DHCPDISCOVER, the DHCP server needs to ignore the subsequent > DHCPDISCOVER messages and wait for the tunnel to be set up. This issue is resolved in -13. > Does the DHCP server also get a subnet mask from the LMA? I suggest > also adding text to the second bullet after Figure 5 that the default > router option in the DHCPOFFER sent to the mobile node be set to the > default router from the mobile node's Binding Cache entry. I don't think the subnet mask issue is resolved in the -14 rev. Text about the default router option was added in the -13 rev, resolving that issue. rev -14 still does not resolve the issue in section 3.4.1 in which the DHCP server should set the Server Identifier option, not siaddr, to the default router address. OLD: The DHCPOFFER message will have the server address field (siaddr) and the default router option set to the mobile node's default router address. NEW: The DHCP server includes a DHCP Server Id option (option code 54) containing the address of the MN's default router, and a Router option (option code 3) containing the address of the MN's default router in a DHCPOFFER message sent to the MN. > Still in section 3.4.1, in the subsection that starts at: > > IPv4 Home Address Renewal with a different DHCP server (After > Handoff): > > How is the mobile node's default router handled during a handoff? > This paragraph implies that the new MAG may have a different address > from the old MAG. But, if the new MAG isn't using the mobile node's > default router address, how are packets forwarded from the mobile > node? I'm still confused by this question in rev -14. Does the MN use the same default IPv4 router throughout the Proxy Mobile IPv6 domain, or is DHCP used to update the default router information? This text in section 3.2.3.2 is relevant: 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 MAY 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. It MAY also use this address as the source address for any datagrams sent to the mobile node and originated by the mobile access gateway itself. It MAY also use this address in the DHCP Router option [RFC-2132] in the DHCP messages. But, why is the configuration of the MAG interface a MAY? Under what circumstance would the MAG not add the MN's default router address to the MAG interface, etc.? If the MAG does not add the MN's default router address to the MAG interface, how does IPv4 routing work? The specific text in the unnumbered section "IPv4 Home Address Renewal with the DHCP server (After Handoff):" seems to be a mix of requirements and recommendations. It seems to recommend the use of the same IPv4 address on all MAGs, but doesn't explain how DHCP will functions if MAGs use different IPv4 addresses. > A better way to handle the case in which nMAG has a different address > than oMAG would be for the nMAG DHCP server to ignore the unicast > RENEWING DHCPREQUEST messages and respond to the broadcast REBINDING > DHCPREQUEST message, which is normal DHCP client behavior for changing > DHCP servers. > > I think the error case in which the nMAG "is unable to complete the > Proxy Mobile IPv6 signaling or is unable to acquire the same IPv4 > address as requested by the mobile node" applies to either case in > this subsection. These issues don't appear to be addressed in -14. > In Section 3.4.2, "Initial IPv4 Home Address Assignment:" should the > MAG check for an assigned IPv4 home address or the existence of the > MAG-LMA tunnel? Or, are those checks equivalent? Is there a reason > that the note "the mobile node needs to be identified by the > MN-Identifier" appears in this step and not the corresponding step in > the process described in section 3.4.1? This issue is addressed in -13. > More generally, I think the corresponding first steps, in which the > MAG receives a DHCPDISCOVER from the mobile node, in sections 3.4.1 > and 3.4.2 are pretty much the same, except for the location of the > DHCP server and relay agents. Yet, the text in the two is much > different; e.g., 3.4.1 defines "the mobile access gateway MUST NOT > enable IPv4 support for the mobile node on that access link" while > 3.4.2 defines "the mobile access gateway will discard the DHCPDISCOVER > messages from the mobile node" as the behaviors in response to failure > to set up the tunnel to the LMA. This issue is addressed in -13. > Still in section 3.4.2, subsection "IPv4 Home Address Renewal to the > same DHCP server: (No Handover)", in the third bullet, why would the > test on the negotiated IPv4 address ever fail and why would the relay > agent drop the DHCPREQUEST message? While this issue is not addressed in -13, I suspect it is a simple belt-and-suspenders check and I consider it closed. > I think section 3.4.3 applies in the situation where the mobile node > stack L3 has received an indication that network reattachment has > happened. It would be clearer to call this event something other than > "handoff", which is used in the previous two sections to indicate that > L3 was not notified of the change in attachment. There is new text (added in rev -13) in section 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. The mobile access gateway on receiving this trigger will check if there is already an assigned IPv4 home address for the mobile node, from the local mobility anchor. If there is no assigned IPv4 home address assigned for that mobile node, the mobile access gateway will complete the Proxy Mobile IPv6 signaling with the local mobility anchor by sending a Proxy Binding Update message. I think this text is somewhat confusing in conjunction with the assumption earlier in this draft and in RFC 5213 that the MAG gets a direct indication of MN attachment. Figure 5 indicates that the PBU/PBA message exchange can take place either before or after the DHCPDISCOVER message is received by the MAG. The text in question remains unchanged in rev -14, More new text in rev -13: o The mobile access gateway will drop all the DHCPDISCOVER messages till it completes the Proxy Mobile IPv6 signaling. If the mobile access gateway is unable to complete the Proxy Mobile IPv6 signaling, or, if the local mobility anchor does not assign an IPv4 address for the mobile node, the mobile access gateway MUST NOT enable IPv4 home address mobility support for the mobile node on that access link. I think this text is in conflict with Figure 5, which indicates that the MAG responds immediately to the previously received DHCPDISCOVER when the PBU/PBA message has completed rather than waiting for the next DHCPDISCOVER. Figure 7 is ambiguous on this point as it shows the initial DHCPDISCOVER arriving at the MAG after the PBU/PBA messages. In rev -14, the relevant figures are 7 and 9, but the text in question is unchanged. More new text from rev -13, unchanged in rev -14: o Any time the mobile node detects a link change event due to handoff, or due to other reasons such as re-establishment of the link-layer, the following are the mobile node's considerations with respect to the DHCP protocol. * If the mobile node is DNAv4 [RFC-4436] capable and if it performs DNAv4 procedures after receiving a link change event, it would always detect the same default router on any of the access links in that Proxy Mobile IPv6 domain, as the mobile access gateway configures a fixed link-layer address on all the access links, as per the base Proxy Mobile IPv6 specification [RFC-5213]. The mobile node will not perform any DHCP operation specifically due to this event. I think this sub-bullet assumes that the MAG has assigned the MN's default router address to the MAG's interface. With that assumption and the assumption that all MAGs use the same link-layer address, the MN using the default router as its test node will not detect a change of network attachment. But, the earlier text does not require that all MAGs use the same IPv4 address. What happens in the case where the MN does detect link change through DNA? * If the mobile node is not DNAv4 [RFC-4436] capable, after receiving the link change event it will enter INIT-REBOOT state [RFC-2131] and will send a DHCPREQUEST message as specified in Section 3.7 of [RFC-2131]. The mobile node will obtain the same address configuration as before, as the link change will not be transparent to the mobile node in that Proxy Mobile IPv6 domain. While the MN may obtain the same address configuration as before (and the details should be spelled out), I don't see how the second half of the last sentence follows from the first half. |
2009-08-05
|
18 | Jari Arkko | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by Jari Arkko |
2009-08-05
|
18 | Jari Arkko | Needs changes based on Pasi's updated Discuss. |
2009-08-04
|
18 | Pasi Eronen | [Ballot discuss] I've updated my discuss based on version -14 of the draft. Many of my concerns have been resolved in this version, but the … [Ballot discuss] I've updated my discuss based on version -14 of the draft. Many of my concerns have been resolved in this version, but the following need some discussion and/or changes: 3) Section 3.4.3 now mentions the Interface MTU DHCP option, but there's nothing about processing of user data packets at MAG/LMA. I expect some existing RFCs already have the details (DF bit, ICMP Too Big, etc. when doing IPv4-over-IPv6 and IPv6-over-IPv4), so possibly pointers to those RFCs (making clear what the MAG and LMA have to implement here) could be enough. 6) Section 4.3 is a big improvement over the earlier versions, and the new figures are really good. However, both of them address only the "incoming packet" part -- there should be similar figure for outgoing packets (when LMA sends PBA, or MAG sends PBU). Also, the text currently covers only PBU/PBA processing, but not the optional payload protection (for MN's data traffic). |
2009-07-26
|
18 | Pasi Eronen | [Ballot discuss] I've updated my discuss based on version -14 of the draft. Many of my concerns have been resolved in this version, but the … [Ballot discuss] I've updated my discuss based on version -14 of the draft. Many of my concerns have been resolved in this version, but the following need some discussion and/or changes: 2) What does the MAG do with the IPv4 subnet mask it receives from the LMA? (Or in other words: what parts of MAG functionality actually use this value for something?) 3) Section 3.4.3 now mentions the Interface MTU DHCP option, but there's nothing about processing of user data packets at MAG/LMA. I expect some existing RFCs already have the details (DF bit, ICMP Too Big, etc. when doing IPv4-over-IPv6 and IPv6-over-IPv4), so possibly pointers to those RFCs (making clear what the MAG and LMA have to implement here) could be enough. 6) Section 4.3 is a big improvement over the earlier versions, and the new figures are really good. However, both of them address only the "incoming packet" part -- there should be similar figure for outgoing packets (when LMA sends PBA, or MAG sends PBU). Also, the text currently covers only PBU/PBA processing, but not the optional payload protection (for MN's data traffic). |
2009-07-15
|
18 | Ralph Droms | [Ballot comment] Is there any impact of lease lengths on the use of DHCP address assignment? If so, guidance would be helpful; if not, explicitly … [Ballot comment] Is there any impact of lease lengths on the use of DHCP address assignment? If so, guidance would be helpful; if not, explicitly mentioning that lease length doesn't matter would be helpful. Nit: s/handover/handoff/ for consistency (I think there is just one occurrence of "handover") Nit: s/default-router/default router/ for consistency (both are used in various places in the document) In section 3.4.1, is there a sentence fragment or some other kind of typo here: The use of fixed DHCP server address on all DHCP servers MN oMAG(DHCP-S) nMAG(DHCP-S) | : | RENEW------------->| 1. DHCPREQUEST (IPv4 HoA) BOUND<-------------| 2. DHCPACK or DHCPNACK | : | Figure 6: Address renewal with a different DHCP server In figure 7, deleted "(IPv4HoA)" in step 4. |
2009-07-15
|
18 | Ralph Droms | [Ballot discuss] I've updated my DISCUSS based on rev -13 of the doc. Some, but not all, of my issues have been addressed. I've added … [Ballot discuss] I've updated my DISCUSS based on rev -13 of the doc. Some, but not all, of my issues have been addressed. I've added comments explaining my responses to the changes in the doc. In addition, I have some new issues with text added to section 3.4.3. > From conversations with the authors, a "handoff" is a change of > network attachment that is not reported to layer 3 as a loss of link > connection. The differentiation between handoff and a change of > network attachment that is reported to L3 is important in section 3.4, > as a DHCP message exchange is triggered by network reconnection > reported to L3. > > The use of 'client identifier' and 'chaddr' in this text from section > 3.4 differs from the use of those fields in DHCP servers. > > o A DHCP server identifies the DHCP client and its interface for > which the address is assigned from the client identifier and the > client hardware address (chaddr) [RFC-2131] fields respectively. > A mobile node in a Proxy Mobile IPv6 domain, can attach to the > network through multiple interfaces and additionally may perform > handoffs between its interfaces. Following are the related > considerations: > > The first issue is that DHCPv4 does not have any concept of multiple > interfaces attached to a single host computer. Each address > assignment - called a 'binding' (this term should be cited as defined > in RFC 2131, to clarify and make distinct from other bindings in this > document) - is regarded as independent, even if the addresses are > assigned to interfaces on the same host. The referenced text has been revised in -13 and is now OK. > The second issue is that the DHCP server uses the client identifier > (if it's available) or the chaddr to identify the entity to which an > address is assigned. Therefore, it's not possible to assign addresses > as suggested in the following text: > > * If the mobile node attaches to the Proxy Mobile IPv6 domain > through multiple interfaces, the DHCP server will uniquely > identify each of those interfaces from the client hardware > address and will perform address assignment. As the mobile > node changes its point of attachment in the network and > performs an handoff to a different mobile access gateway, using > the same interface, the DHCP server will always be able to > identify the binding using the presented client hardware > address. The client hardware address and client identifier > will remain as the primary keys for each binding, just as how > they are unique in a Binding Cache entry. > > Specifically, the client identifier is the identifier for a binding, > so there is no concept of using both the client identifier and > hardware address as primary keys. > > So, I think I understand what's going on in this first sub-bullet > (although the first sentence seems out of place). The preceding bullet appears to be unchanged in -13, and my earlier comments still apply. > The second sub-bullet, if I understand it correctly, is also easy to > fix: > > * However, if the mobile node is capable of performing handoff > between interfaces, as per [RFC-5213], the client hardware > address 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. > > I'm guessing that the idea here is to move the IPv4 address from > interface A to interface B when the handoff happens. If I've got that > right, then the client needs to use the same client identifier for any > subsequent DHCP message exchanges on interface B. > > I'm still not clear about how the use of multiple simultaneous > interfaces fits into the model. The preceding bullet also appears to be unchanged in -13, and my earlier comments still apply. > Section 3.4.1 needs some additional detail to describe what happens > when the steps 2-4 in Figure 5 occur before step 1. When the DHCP > server receives the DHCPDISCOVER message, it needs to check to see if > the tunnel is already set up. > > If the tunnel setup is not complete before the DHCP client retransmits > the DHCPDISCOVER, the DHCP server needs to ignore the subsequent > DHCPDISCOVER messages and wait for the tunnel to be set up. This issue is resolved in -13. > Does the DHCP server also get a subnet mask from the LMA? I suggest > also adding text to the second bullet after Figure 5 that the default > router option in the DHCPOFFER sent to the mobile node be set to the > default router from the mobile node's Binding Cache entry. These questions still need to be addressed by adding text about where the DHCP server gets the subnet mask for the MN, and that the DHCPOFFER needs to supply the Subnet Mask option and the Default Router option to the MN. Also, on re-reading this section more carefully, I see that the DHCP server should set the Server Identifier option, not siaddr, to the default router address. > Still in section 3.4.1, in the subsection that starts at: > > IPv4 Home Address Renewal with a different DHCP server (After > Handoff): > > How is the mobile node's default router handled during a handoff? > This paragraph implies that the new MAG may have a different address > from the old MAG. But, if the new MAG isn't using the mobile node's > default router address, how are packets forwarded from the mobile > node? I'm still confused by this question, and in trying to understand the mechanism, I realized I must be missing something in the underlying addressing model. Does the MN use the same default IPv4 router throughout the Proxy Mobile IPv6 domain, or is DHCP used to update the default router information? This text in section 3.2.3.2 is relevant: 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 MAY 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. It MAY also use this address as the source address for any datagrams sent to the mobile node and originated by the mobile access gateway itself. It MAY also use this address in the DHCP Router option [RFC-2132] in the DHCP messages. But, why is the configuration of the MAG interface a MAY? Under what circumstance would the MAG not add the MN's default router address to the MAG interface, etc.? If the MAG does not add the MN's default router address to the MAG interface, how does IPv4 routing work? > A better way to handle the case in which nMAG has a different address > than oMAG would be for the nMAG DHCP server to ignore the unicast > RENEWING DHCPREQUEST messages and respond to the broadcast REBINDING > DHCPREQUEST message, which is normal DHCP client behavior for changing > DHCP servers. > > I think the error case in which the nMAG "is unable to complete the > Proxy Mobile IPv6 signaling or is unable to acquire the same IPv4 > address as requested by the mobile node" applies to either case in > this subsection. These issues don't appear to be addressed in -13. > In Section 3.4.2, "Initial IPv4 Home Address Assignment:" should the > MAG check for an assigned IPv4 home address or the existence of the > MAG-LMA tunnel? Or, are those checks equivalent? Is there a reason > that the note "the mobile node needs to be identified by the > MN-Identifier" appears in this step and not the corresponding step in > the process described in section 3.4.1? This issue is addressed in -13. > More generally, I think the corresponding first steps, in which the > MAG receives a DHCPDISCOVER from the mobile node, in sections 3.4.1 > and 3.4.2 are pretty much the same, except for the location of the > DHCP server and relay agents. Yet, the text in the two is much > different; e.g., 3.4.1 defines "the mobile access gateway MUST NOT > enable IPv4 support for the mobile node on that access link" while > 3.4.2 defines "the mobile access gateway will discard the DHCPDISCOVER > messages from the mobile node" as the behaviors in response to failure > to set up the tunnel to the LMA. This issue is addressed in -13. > Still in section 3.4.2, subsection "IPv4 Home Address Renewal to the > same DHCP server: (No Handover)", in the third bullet, why would the > test on the negotiated IPv4 address ever fail and why would the relay > agent drop the DHCPREQUEST message? While this issue is not addressed in -13, I suspect it is a simple belt-and-suspenders check and I consider it closed. > I think section 3.4.3 applies in the situation where the mobile node > stack L3 has received an indication that network reattachment has > happened. It would be clearer to call this event something other than > "handoff", which is used in the previous two sections to indicate that > L3 was not notified of the change in attachment. There is new text in section 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. The mobile access gateway on receiving this trigger will check if there is already an assigned IPv4 home address for the mobile node, from the local mobility anchor. If there is no assigned IPv4 home address assigned for that mobile node, the mobile access gateway will complete the Proxy Mobile IPv6 signaling with the local mobility anchor by sending a Proxy Binding Update message. I think this text is somewhat confusing in conjunction with the assumption earlier in this draft and in RFC 5213 that the MAG gets a direct indication of MN attachment. Figure 5 indicates that the PBU/PBA message exchange can take place either before or after the DHCPDISCOVER message is received by the MAG. More new text: o The mobile access gateway will drop all the DHCPDISCOVER messages till it completes the Proxy Mobile IPv6 signaling. If the mobile access gateway is unable to complete the Proxy Mobile IPv6 signaling, or, if the local mobility anchor does not assign an IPv4 address for the mobile node, the mobile access gateway MUST NOT enable IPv4 home address mobility support for the mobile node on that access link. I think this text is in conflict with Figure 5, which indicates that the MAG responds immediately to the previously received DHCPDISCOVER when the PBU/PBA message has completed rather than waiting for the next DHCPDISCOVER. Figure 7 is ambiguous on this point as it shows the initial DHCPDISCOVER arriving at the MAG after the PBU/PBA messages. More new text: o Any time the mobile node detects a link change event due to handoff, or due to other reasons such as re-establishment of the link-layer, the following are the mobile node's considerations with respect to the DHCP protocol. * If the mobile node is DNAv4 [RFC-4436] capable and if it performs DNAv4 procedures after receiving a link change event, it would always detect the same default router on any of the access links in that Proxy Mobile IPv6 domain, as the mobile access gateway configures a fixed link-layer address on all the access links, as per the base Proxy Mobile IPv6 specification [RFC-5213]. The mobile node will not perform any DHCP operation specifically due to this event. I think this sub-bullet assumes that the MAG has assigned the MN's default router address to the MAG's interface. With that assumption and the assumption that all MAGs use the same link-layer address, the MN using the default router as its test node will not detect a change of network attachment. * If the mobile node is not DNAv4 [RFC-4436] capable, after receiving the link change event it will enter INIT-REBOOT state [RFC-2131] and will send a DHCPREQUEST message as specified in Section 3.7 of [RFC-2131]. The mobile node will obtain the same address configuration as before, as the link change will not be transparent to the mobile node in that Proxy Mobile IPv6 domain. While the MN may obtain the same address configuration as before (and the details should be spelled out), I don't see how the second half of the last sentence follows from the first half. |
2009-07-14
|
18 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
2009-07-13
|
14 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-14.txt |
2009-06-30
|
18 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-06-30
|
13 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-13.txt |
2009-06-24
|
18 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation - Defer::Revised ID Needed by Amy Vezza |
2009-06-05
|
18 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Stephen Farrell. |
2009-06-04
|
18 | Cindy Morgan | State Changes to IESG Evaluation - Defer::Revised ID Needed from IESG Evaluation - Defer by Cindy Morgan |
2009-06-04
|
18 | Jari Arkko | [Ballot discuss] Waiting for updated IANA considerations section per request from IANA. |
2009-06-04
|
18 | Jari Arkko | [Ballot Position Update] Position for Jari Arkko has been changed to Discuss from Yes by Jari Arkko |
2009-06-04
|
18 | Pasi Eronen | [Ballot discuss] I have reviewed draft-ietf-netlmm-pmip6-ipv4-support-12, and have couple of questions/concerns that I'd like to discuss before recommending approval of the document: 1) When … [Ballot discuss] I have reviewed draft-ietf-netlmm-pmip6-ipv4-support-12, and have couple of questions/concerns that I'd like to discuss before recommending approval of the document: 1) When the MN attaches to an access link, how does the MAG determine whether the MN is IPv4-only, IPv6-only, or dual-stack? Figure 3.4.1 suggests the MAG would wait until it receives DHCPDISCOVER before sending the PBU -- but if the MN host has e.g. disabled IPv4, the DHCPDISCOVER will never come...? While the policy profile might tell whether the user is authorized for IPv4, IPv6, or both, that doesn't necessarily tell what the actual hosts supports -- the user might have changed the configuration, upgraded from XP to Vista, or something. 2) I had some difficulties in understanding what the text about "subnet mask" means. It seems this specification doesn't support allocating an IPv4 prefix to the MN, only a single address, right? In this situation, draft-ietf-mext-nemo-v4-traversal says that the Prefix-len field in IPv4 Home Address Option is set to 32. But if the MN gets only a single IPv4 (home) address, what does the MAG do with subnet masks? 3) I was expecting to see some text about MTU and related issues (at least pointers to other documents -- quite obviously, the text in base PMIP6 doesn't work as is here), and perhaps something about the Interface MTU DHCP option. But the draft never mentions MTU at all? 4) Section 3.4.1 says that when the MN needs to send a DHCP lease renewal, but it has moved to a different MAG, "it is required that the mobile node updates the DHCP server address and uses the address of the DHCP server that is co-located with the new mobile access gateway". How does this happen? Does this require PMIP-specific modifications to the DHCP code? 5) Section 3.4.3 says DHCPRELEASE "should not release any IPv6 home network prefix(es) assigned to the mobile node". Why isn't this "MUST NOT release..."? 6) RFC 5213 uses IPsec in a very simple way (much simpler than client Mobile IPv6), and doesn't really require anything Mobile IP specific from the IPsec stack (beyond using MH type as traffic selector). The text in Section 4 isn't very clear on how IPsec would be used (e.g. what the SAD/SPD entries would be?) here, but it seems to assume some unspecified modifications to the IPsec stack (perhaps similar to DSMIPv6, but it's not clear). This text needs to be significantly clearer on how the IPsec processing would actually work, and what the SAs (negotiated by e.g. IKEv2) would actually be. I would really prefer if we could keep this simpler than DSMIPv6 (where the IPsec parts are absolutely horrible). 7) Section 3.3.2: The IPv4 DHCP Support Mode option has number of bits reserved for future use. Should there be an IANA registry? 8) IANA considerations doesn't mention the IPv4 DHCP Support Mode Option? |
2009-06-04
|
18 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
2009-06-04
|
18 | Tim Polk | [Ballot comment] Paraphrased from Stephen Farrell's secdir review: 3.1.2.7 says: "when there is not a single Home Network Prefix option with NON_ZERO value present in … [Ballot comment] Paraphrased from Stephen Farrell's secdir review: 3.1.2.7 says: "when there is not a single Home Network Prefix option with NON_ZERO value present in the request..." That's very hard to interpret and possibly badly ambiguous. "Not a single" could mean zero or >1. Perhaps "when there are no Home Network Prefix options with a NON_ZERO value present in the request ..." would be clearer. 3.1.3 says that the mobility anchor MUST advertise a connected route but doesn't say how. Perhaps a reference is in order here? section 7: s/news/new/ |
2009-06-04
|
18 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2009-06-04
|
18 | Robert Sparks | [Ballot Position Update] New position, No Objection, has been recorded by Robert Sparks |
2009-06-04
|
18 | Dan Romascanu | [Ballot comment] The OPSA-DIR review included a number of editorial comments. None of them is a show stopper, but incase the document goes though a … [Ballot comment] The OPSA-DIR review included a number of editorial comments. None of them is a show stopper, but incase the document goes though a revision for other reasons I suggest that they are considered. |
2009-06-03
|
18 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2009-06-03
|
18 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2009-05-29
|
18 | Jari Arkko | [Note]: 'Document Shepherd is Vidya Narayanan <vidyan@qualcomm.com>' added by Jari Arkko |
2009-05-22
|
18 | (System) | Removed from agenda for telechat - 2009-05-21 |
2009-05-20
|
18 | Adrian Farrel | [Ballot Position Update] New position, No Objection, has been recorded by Adrian Farrel |
2009-05-20
|
18 | Adrian Farrel | [Ballot comment] I have raised my issues as Comments as they are all editorial. But the volume of issues brings them very close to being … [Ballot comment] I have raised my issues as Comments as they are all editorial. But the volume of issues brings them very close to being bundled together as a Discuss. === I know that the RFC Editor can sort a lot of this out, and it is no criticism of the authors, but the reviews would be smoother and more likely to focus on technical details if in future you could get someone to take a pass on the English of the document preferably before WG last call. Fixing some of the language has the potential to accidentally break the meaning of the text, and you cannot rely on the RFC Editor to understand all of the technical details. === Section 1 It is also reasonable to expect the same mobility infrastructure in the Proxy Mobile IPv6 domain to provide mobility to the mobile nodes operating in IPv4, IPv6 or in dual mode and when the network between the local mobility anchor and the mobile access gateway is an IPv4 or an IPv6 network. I can't parse this sentence. I get lost around "and when". Any chance of a rephrase? === Section 1 bullet 1 The mobile node is not required to be allocated or assigned an IPv6 address for enabling IPv4 home address support. I think you mean s/for enabling/to enable/ but this is a subtly different meaning. === Figure 1 This figure is an orphan! I can't find any text that refers to it and it really needs some explanation. It also uses some acronyms that aren't explained until quite a bit later. It *is* good to have a figure early in the I-D, but you can't just plonk it in. === Section 1.1 The section title is clear, and the bullet points appear to match the title, but the introduction paragraph: The following are the configuration requirements from the mobility entities in the Proxy Mobile IPv6 domain for supporting the extensions defined in this document. talks of configuration requirements and is only relevant to some of the assumptions. Separate assumptions from configuration requirements? === Figure 2 also uses some acronyms/identifiers that are not explained. === I don't find the use of "IPv4 default-router" and "IPv4 default-router address" very clear. In 1.1 there is The mobile access gateway is the IPv4 default-router for the mobile node on its access link. which is clear. But later (3.1.1 etc. and even in 3.3.1) The IPv4 default-router address assigned to the mobile node. Can you make this clear throughout the document (search on default- router) whether this is an address assigned to the mobile node (i.e. and address of the mobile node) or the address of the default-router that has been assigned to the mobile node (i.e. the address of the default-router). === 3.3.2 You might consider creating a registry for bits in the DHCP Support Mode Option. === The IANA section seems to be deficient in detail and also missing the IPv4 DHCP Support Mode Option. But I see that IANA has an open issue to be addressed by the authors. === |
2009-05-19
|
18 | Pasi Eronen | State Changes to IESG Evaluation - Defer from Waiting for AD Go-Ahead by Pasi Eronen |
2009-05-19
|
18 | Ralph Droms | [Ballot discuss] From conversations with the authors, a "handoff" is a change of network attachment that is not reported to layer 3 as a loss … [Ballot discuss] From conversations with the authors, a "handoff" is a change of network attachment that is not reported to layer 3 as a loss of link connection. The differentiation between handoff and a change of network attachment that is reported to L3 is important in section 3.4, as a DHCP message exchange is triggered by network reconnection reported to L3. The use of 'client identifier' and 'chaddr' in this text from section 3.4 differs from the use of those fields in DHCP servers. o A DHCP server identifies the DHCP client and its interface for which the address is assigned from the client identifier and the client hardware address (chaddr) [RFC-2131] fields respectively. A mobile node in a Proxy Mobile IPv6 domain, can attach to the network through multiple interfaces and additionally may perform handoffs between its interfaces. Following are the related considerations: The first issue is that DHCPv4 does not have any concept of multiple interfaces attached to a single host computer. Each address assignment - called a 'binding' (this term should be cited as defined in RFC 2131, to clarify and make distinct from other bindings in this document) - is regarded as independent, even if the addresses are assigned to interfaces on the same host. The second issue is that the DHCP server uses the client identifier (if it's available) or the chaddr to identify the entity to which an address is assigned. Therefore, it's not possible to assign addresses as suggested in the following text: * If the mobile node attaches to the Proxy Mobile IPv6 domain through multiple interfaces, the DHCP server will uniquely identify each of those interfaces from the client hardware address and will perform address assignment. As the mobile node changes its point of attachment in the network and performs an handoff to a different mobile access gateway, using the same interface, the DHCP server will always be able to identify the binding using the presented client hardware address. The client hardware address and client identifier will remain as the primary keys for each binding, just as how they are unique in a Binding Cache entry. Specifically, the client identifier is the identifier for a binding, so there is no concept of using both the client identifier and hardware address as primary keys. So, I think I understand what's going on in this first sub-bullet (although the first sentence seems out of place). The second sub-bullet, if I undertstand it correctly, is also easy to fix: * However, if the mobile node is capable of performing handoff between interfaces, as per [RFC-5213], the client hardware address 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. I'm guessing that the idea here is to move the IPv4 address from interface A to interface B when the handoff happens. If I've got that right, then the client needs to use the same client identifier for any subsequent DHCP message exchanges on interface B. I'm still not clear about how the use of multiple simultaneous interfaces fits into the model. Section 3.4.1 needs some additional detail to describe what happens when the steps 2-4 in Figure 5 occur before step 1. When the DHCP server receives the DHCPDISCOVER message, it needs to check to see if the tunnel is already set up. If the tunnel setup is not complete before the DHCP client retransmits the DHCPDISCOVER, the DHCP server needs to ignore the subsequent DHCPDISCOVER messages and wait for the tunnel to be set up. Does the DHCP server also get a subnet mask from the LMA? I suggest also adding text to the second bullet after Figure 5 that the default router option in the DHCPOFFER sent to the mobile node be set to the default router from the mobile node's Binding Cache entry. Still in section 3.4.1, in the subsection that starts at: IPv4 Home Address Renewal with a different DHCP server (After Handoff): How is the mobile node's default router handled during a handoff? This paragraph implies that the new MAG may have a different address from the old MAG. But, if the new MAG isn't using the mobile node's default router address, how are packets forwarded from the mobile node? A better way to handle the case in which nMAG has a different address than oMAG would be for the nMAG DHCP server to ignore the unicast RENEWING DHCPREQUEST messages and respond to the broadcast REBINDING DHCPREQUEST message, which is normal DHCP client behavior for changing DHCP servers. I think the error case in which the nMAG "is unable to complete the Proxy Mobile IPv6 signaling or is unable to acquire the same IPv4 address as requested by the mobile node" applies to either case in this subsection. In Section 3.4.2, "Initial IPv4 Home Address Assignment:" should the MAG check for an assigned IPv4 home address or the existence of the MAG-LMA tunnel? Or, are those checks equivalent? Is there a reason that the note "the mobile node needs to be identified by the MN-Identifier" appears in this step and not the corresponding step in the process described in section 3.4.1? More generally, I think the corresponding first steps, in which the MAG receives a DHCPDISCOVER from the mobile node, in sections 3.4.1 and 3.4.2 are pretty much the same, except for the location of the DHCP server and relay agents. Yet, the text in the two is much different; e.g., 3.4.1 defines "the mobile access gateway MUST NOT enable IPv4 support for the mobile node on that access link" while 3.4.2 defines "the mobile access gateway will discard the DHCPDISCOVER messages from the mobile node" as the behaviors in response to failure to set up the tunnel to the LMA. Still in section 3.4.2, subsection "IPv4 Home Address Renewal to the same DHCP server: (No Handover)", in the third bullet, why would the test on the negotiated IPv4 address ever fail and why would the relay agent drop the DHCPREQUEST message? I think section 3.4.3 applies in the situation where the mobile node stack L3 has received an indication that network reattachment has happened. It would be clearer to call this event something other than "handoff", which is used in the previous two sections to indicate that L3 was not notified of the change in attachment. |
2009-05-19
|
18 | Ralph Droms | [Ballot comment] Is there any impact of lease lengths on the use of DHCP address assignment? If so, guidance would be helpful; if not, explicitly … [Ballot comment] Is there any impact of lease lengths on the use of DHCP address assignment? If so, guidance would be helpful; if not, explicitly mentioning that lease length doesn't matter would be helpful. Nit: s/handover/handoff/ for consistency (I think there is just one occurrence of "handover") Nit: s/default-router/default router/ for consistency (both are used in various places in the document) In section 3.4.1, is there a sentence fragment or some other kind of typo here: The use of fixed DHCP server address on all DHCP servers MN oMAG(DHCP-S) nMAG(DHCP-S) | : | RENEW------------->| 1. DHCPREQUEST (IPv4 HoA) BOUND<-------------| 2. DHCPACK or DHCPNACK | : | Figure 6: Address renewal with a different DHCP server In figure 7, deleted "(IPv4HoA)" in step 4. |
2009-05-19
|
18 | Ralph Droms | [Ballot Position Update] New position, Discuss, has been recorded by Ralph Droms |
2009-05-19
|
18 | Russ Housley | [Ballot discuss] Spencer Dawkins posted an extensive Gen-ART Review. See http://www.ietf.org/mail-archive/web/gen-art/current/msg04081.html The review has resulted in some additional discussion, which is also … [Ballot discuss] Spencer Dawkins posted an extensive Gen-ART Review. See http://www.ietf.org/mail-archive/web/gen-art/current/msg04081.html The review has resulted in some additional discussion, which is also in the Gen-ART mail archive. It is pretty clear to me that an update to the Internet-Draft is needed once the discussion converges. |
2009-05-19
|
18 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded by Russ Housley |
2009-05-19
|
18 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2009-05-19
|
18 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2009-05-19
|
18 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2009-05-18
|
18 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2009-05-14
|
18 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2009-05-14
|
18 | Jari Arkko | Ballot has been issued by Jari Arkko |
2009-05-14
|
18 | Jari Arkko | Created "Approve" ballot |
2009-05-13
|
18 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Stephen Farrell |
2009-05-13
|
18 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Stephen Farrell |
2009-05-13
|
18 | Amanda Baber | IANA questions/comments: - The IANA consideration section is not clear on what actions are requested of IANA. In addition, there appear to be allocation requests … IANA questions/comments: - The IANA consideration section is not clear on what actions are requested of IANA. In addition, there appear to be allocation requests in sections not pointed to by the IANA Considerations. - The IANA Considerations references section 3.3.2 for Action 2, but the registrations are in section 3.3.3. You should copy the list by value into the IANA Considerations Section. - Section 3.3.2 defines a new Option (DHCP Support Mode) that is not referenced in the IANA Considerrations Section. You should add this registration to the IANA Considerations Section. Action 1: Upon approval of this document, IANA will make the following assignment in the "Mobility Options" registry at http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml Value Description Reference ----- ----------- --------- tbd IPv4 Default Router Address [RFC-netlmm-pmip6-ipv4-support-12] Action 2: Upon approval of this document, IANA will make the following assignments in the "Status Codes" registry at http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml Value Description Reference ----- ----------- --------- tbd NOT_AUTHORIZED_FOR_IPV4_HOME_ADDRESS [RFC-netlmm-pmip6-ipv4-support-12] tbd NOT_AUTHORIZED_FOR_IPV6_HOME_NETWORK_PREFIX [RFC-netlmm-pmip6-ipv4-support-12] tbd MULTIPLE_IPV4_HOME_ADDRESS_ASSIGNMENT_NOT_SUPPORTED [RFC-netlmm-pmip6-ipv4-support-12] tbd IPV4_PREFIX_ASSIGNMENT_NOT_SUPPORTED [RFC-netlmm-pmip6-ipv4-support-12] |
2009-05-05
|
18 | Jari Arkko | Placed on agenda for telechat - 2009-05-21 by Jari Arkko |
2009-05-04
|
18 | Amy Vezza | Last call sent |
2009-05-04
|
18 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2009-05-02
|
18 | Jari Arkko | State Changes to Last Call Requested from AD Evaluation::External Party by Jari Arkko |
2009-05-02
|
18 | Jari Arkko | Last Call was requested by Jari Arkko |
2009-05-02
|
18 | (System) | Ballot writeup text was added |
2009-05-02
|
18 | (System) | Last call text was added |
2009-05-02
|
18 | (System) | Ballot approval text was added |
2009-04-23
|
12 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-12.txt |
2009-04-13
|
18 | Jari Arkko | State Changes to AD Evaluation::External Party from AD Evaluation::AD Followup by Jari Arkko |
2009-04-13
|
18 | Jari Arkko | waiting for WG conclusion on a remaining issue |
2009-04-08
|
18 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-04-08
|
11 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-11.txt |
2009-04-08
|
18 | Jari Arkko | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::AD Followup by Jari Arkko |
2009-04-08
|
18 | Jari Arkko | small revision is still needed |
2009-03-24
|
18 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-03-24
|
10 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-10.txt |
2009-02-18
|
18 | Jari Arkko | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jari Arkko |
2009-01-28
|
18 | Amy Vezza | # (1.a) Who is the Document Shepherd for this document? Has the Document # Shepherd personally reviewed this version of the document and, in particular, … # (1.a) Who is the Document Shepherd for this document? Has the Document # Shepherd personally reviewed this version of the document and, in particular, # does he or she believe this version is ready for forwarding to the IESG for # publication? Document Shepherd is Vidya Narayanan. I have personally reviewed the document and I believe the document is ready for publication. # (1.b) Has the document had adequate review both from key WG members and from # key non-WG members? Does the Document Shepherd have any concerns about the # depth or breadth of the reviews that have been performed? The document has had extensive reviews within the WG. I do not have any concerns about the depth or breadth of reviews received. # (1.c) Does the Document Shepherd have concerns that the document needs more # review from a particular or broader perspective, e.g., security, operational # complexity, someone familiar with AAA, internationalization or XML? I have no concerns about the reviews for this document. # (1.d) Does the Document Shepherd have any specific concerns or issues with # this document that the Responsible Area Director and/or the IESG should be # aware of? For example, perhaps he or she is uncomfortable with certain parts # of the document, or has concerns whether there really is a need for it. In # any event, if the WG has discussed those issues and has indicated that it # still wishes to advance the document, detail those concerns here. Has an # IPR disclosure related to this document been filed? If so, please include a # reference to the disclosure and summarize the WG discussion and conclusion # on this issue. I have no concerns on the document. There have been no IPR disclosures filed on this document. # (1.e) How solid is the WG consensus behind this document? Does it # represent the strong concurrence of a few individuals, with others # being silent, or does the WG as a whole understand and agree with it? There is a strong consensus behind the document. # (1.f) Has anyone threatened an appeal or otherwise indicated extreme # discontent? If so, please summarise the areas of conflict in separate # email messages to the Responsible Area Director. (It should be in a # separate email because this questionnaire is entered into the ID Tracker.) Nobody has threatened to appeal and the document is a product of the WG as a whole. # (1.g) Has the Document Shepherd personally verified that the document # satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and # http://tools.ietf.org/tools/idnits/). Boilerplate checks are not # enough; this check needs to be thorough. Has the document met all formal # review criteria it needs to, such as the MIB Doctor, media type and URI # type reviews? ID Nits produces a couple of warnings about non RFC3330 compliant IP addresses on section numbers that appears to be a bug in ID Nits. Otherwise, there are no ID nits errors or warnings on the document. # (1.h) Has the document split its references into normative and informative? # Are there normative references to documents that are not ready for # advancement or are otherwise in an unclear state? If such normative # references exist, what is the strategy for their completion? Are there # normative references that are downward references, as described in # [RFC3967]? If so, list these downward references to support the Area # Director in the Last Call procedure for them [RFC3967]. There is a split to normative and informative references. The document has draft-ietf-mext-nemo-v4traversal as a normative reference. This draft is already in IESG evaluation and is expected to be published soon. So, there is no concern on having normative references in an unclear state. There are no downward references in the document. # (1.i) Has the Document Shepherd verified that the document IANA # consideration section exists and is consistent with the body of the # document? If the document specifies protocol extensions, are reservations # requested in appropriate IANA registries? Are the IANA registries clearly # identified? If the document creates a new registry, does it define the # proposed initial contents of the registry and an allocation procedure for # future registrations? Does it suggest a reasonable name for the new # registry? See [RFC2434]. If the document describes an Expert Review # process has Shepherd conferred with the Responsible Area Director so that # the IESG can appoint the needed Expert during the IESG Evaluation? Yes, IANA considerations section does exist and seems to be in line with the rest of the document. # (1.j) Has the Document Shepherd verified that sections of the document that # are written in a formal language, such as XML code, BNF rules, MIB # definitions, etc., validate correctly in an automated checker? No formal language segments exist. # (1.k) The IESG approval announcement includes a Document Announcement # Write-Up. Please provide such a Document Announcement Write-Up? Recent # examples can be found in the "Action" announcements for approved documents. # The approval announcement contains the following sections: Technical Summary The Proxy Mobile IPv6 specification in RFC 5213 describes network based mobility management for IPv6 hosts across IPv6 network domains. This document describes the necessary extensions to RFC 5213 to support IPv4-only and dual stacked hosts. It also supports IPv4 network traversal between the Mobile Access Gateway (MAG) in the access network and the Local Mobility Anchor (LMA). Working Group Summary There is a consensus in the NETLMM WG for publication as a proposed standard. Document Quality The document has gone through various reviews and a successful WGLC. Personnel Responsible AD is Jari Arkko and the document shepherd is Vidya Narayanan. |
2009-01-28
|
18 | Jari Arkko | State Changes to AD Evaluation from Publication Requested::External Party by Jari Arkko |
2009-01-21
|
18 | Jari Arkko | State Changes to Publication Requested::External Party from Publication Requested::Revised ID Needed by Jari Arkko |
2009-01-21
|
18 | Jari Arkko | waiting for shepherd writeup |
2009-01-21
|
18 | Jari Arkko | Draft Added by Jari Arkko in state Publication Requested |
2009-01-21
|
09 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-09.txt |
2009-01-19
|
08 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-08.txt |
2008-12-17
|
07 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-07.txt |
2008-11-28
|
06 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-06.txt |
2008-09-23
|
05 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-05.txt |
2008-07-14
|
04 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-04.txt |
2008-05-28
|
03 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-03.txt |
2007-11-19
|
02 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-02.txt |
2007-07-09
|
01 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-01.txt |
2007-04-26
|
00 | (System) | New version available: draft-ietf-netlmm-pmip6-ipv4-support-00.txt |