Dual-Stack Mobile IPv4
draft-ietf-mip4-dsmipv4-10
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2012-08-22
|
10 | (System) | post-migration administrative database adjustment to the No Objection position for Pasi Eronen |
2009-01-30
|
10 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2009-01-30
|
10 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
2009-01-30
|
10 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
2009-01-21
|
10 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2009-01-20
|
10 | (System) | IANA Action state changed to In Progress |
2009-01-20
|
10 | Cindy Morgan | State Changes to RFC Ed Queue from Approved-announcement sent by Cindy Morgan |
2009-01-20
|
10 | Amy Vezza | IESG state changed to Approved-announcement sent |
2009-01-20
|
10 | Amy Vezza | IESG has approved the document |
2009-01-20
|
10 | Amy Vezza | Closed "Approve" ballot |
2009-01-19
|
10 | Jari Arkko | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Jari Arkko |
2009-01-19
|
10 | Pasi Eronen | [Ballot Position Update] Position for Pasi Eronen has been changed to No Objection from Discuss by Pasi Eronen |
2009-01-15
|
10 | (System) | New version available: draft-ietf-mip4-dsmipv4-10.txt |
2009-01-13
|
10 | Pasi Eronen | [Ballot discuss] I have reviewed draft-ietf-mip4-dsmipv4-08, and I have the following concerns that I'd like to discuss before recommending approval of the document: - … [Ballot discuss] I have reviewed draft-ietf-mip4-dsmipv4-08, and I have the following concerns that I'd like to discuss before recommending approval of the document: - I have some difficulties in understanding how the foreign agent care-of address mode works with when tunneling IPv6 to the CoA. In particular, the spec doesn't really explain what happens on the link between MN and FA -- things like Neighbor Discovery (and configuring addresses and DAD in general), Router Advertisements, link-local addresses, MLD/link-scope multicast, handling of hop limit, and so on. (It seems the details may depend on the negotiated "delivery style", too). - Section 4.3.2 says that Minimal Encapsulation (RFC 2004) could be used for IPv6 traffic, too -- but I can't quite see how this would work (among other things, the address fields in the RFC 2004 minimal forwarding header are only 32 bits). - Section 4.5 says that "the mobile node SHOULD assume that these IPv6 prefixes are rejected" if they're not included in the reply. What are the circumstances when the MN can assume they were *not* rejected, and what does it do then? (That is, why this is not a MUST?) Then to the usual issues with specs that do IP tunneling: - The spec needs to say something about fragmentation and path MTU discovery. RFC 4213 gives some options to choose from, but this spec needs to e.g. decide between static or dynamic tunnel MTU (and for static MTU, the value to be used). - The spec says IPv6-in-IPv4 tunneling is done as specified in RFC 4213. We should add a paragraph highlighting some of the less-than-obvious impacts of RFC 4213: (1) Both MN and HA must configure a link-local addresses for the tunnel (Section 3.7) -- this spec needs to give the details of how this is done (e.g. if the construction given in Section 3.7 of RFC 4213 is used, we can skip DAD), and (2) Both MN and HA must support Neighbor Discovery over the tunnel (Section 3.8). |
2009-01-08
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2009-01-08
|
09 | (System) | New version available: draft-ietf-mip4-dsmipv4-09.txt |
2008-12-05
|
10 | (System) | Removed from agenda for telechat - 2008-12-04 |
2008-12-04
|
10 | Amy Vezza | State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza |
2008-12-04
|
10 | David Ward | [Ballot Position Update] New position, No Objection, has been recorded by David Ward |
2008-12-04
|
10 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault |
2008-12-04
|
10 | Ross Callon | [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon |
2008-12-04
|
10 | Ron Bonica | [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica |
2008-12-04
|
10 | Magnus Westerlund | [Ballot comment] I don't have the time to wrap my head about this question so I am going to ask directly instead. I hope I … [Ballot comment] I don't have the time to wrap my head about this question so I am going to ask directly instead. I hope I can get an answer. Does this MIP4 extension deal with the case when there is a v4<->v6 address family translator between the MN and the FN or HA? Can this operate in such an environment without an application level gateway that support MIP4? |
2008-12-04
|
10 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund |
2008-12-04
|
10 | Pasi Eronen | [Ballot discuss] I have reviewed draft-ietf-mip4-dsmipv4-08, and I have the following concerns that I'd like to discuss before recommending approval of the document: - … [Ballot discuss] I have reviewed draft-ietf-mip4-dsmipv4-08, and I have the following concerns that I'd like to discuss before recommending approval of the document: - I have some difficulties in understanding how the foreign agent care-of address mode works with when tunneling IPv6 to the CoA. In particular, the spec doesn't really explain what happens on the link between MN and FA -- things like Neighbor Discovery (and configuring addresses and DAD in general), Router Advertisements, link-local addresses, MLD/link-scope multicast, handling of hop limit, and so on. (It seems the details may depend on the negotiated "delivery style", too). - Section 4.3.2 says "The home agent SHOULD check that all inner IPv6 packets received from the mobile node over a tunnel [..] include a source address that falls under the registered IPv6 prefix(es) for that mobile node." I don't quite see why this is "SHOULD" instead of "MUST"? (Allowing MNs to spoof their source address doesn't sound like a good idea.) - Section 4.3.2 says that Minimal Encapsulation (RFC 2004) could be used for IPv6 traffic, too -- but I can't quite see how this would work (among other things, the address fields in the RFC 2004 minimal forwarding header are only 32 bits). - Section 4.8: RFC 3519 requires that the "Next Header" field in the Mobile Tunnel Data message header matches the value of the "Encapsulation" field in Registration Reply. Wouldn't just setting the "Next Header" to IPv6 mean the packet is dropped? - Section 4.6.1 seems to suggest tunneling IPv6 traffic to the home agent even if no DSMIPv4 extensions were included in registration reply (and MN does not know that the HA supports DSMIPv4 -- and even if it does, it may not support DHCPv6 PD). Is this a good idea? Wouldn't it be better to explicitly signal that DHCPv6 PD will be used (and a tunnel for link-local traffic is set up) with an extension in registration request/reply? - Section 4.3.3, says that MLD must be tunneled "between the mobile node and the home agent, bypassing the foreign agent". Does this mean "tunneled to the IPv4 HoA"? (The next sentence talks about tunneling rest of the traffic to CoA...) - Section 4.5 says that "the mobile node SHOULD assume that these IPv6 prefixes are rejected" if they're not included in the reply. What are the circumstances when the MN can assume they were *not* rejected, and what does it do then? (That is, why this is not a MUST?) Then to the usual issues with specs that do IP tunneling: - The spec needs to say something about fragmentation and path MTU discovery. RFC 4213 gives some options to choose from, but this spec needs to e.g. decide between static or dynamic tunnel MTU (and for static MTU, the value to be used). - The spec should say something about the DSCP field and ECN bits. At minimum, this would be setting the outer DSCP to 0 (or in implementation dependent way), and using the RFC3168 "limited- functionality option" for ECN. But "full-functionality option" for ECN could be a good idea, too. - The spec says IPv6-in-IPv4 tunneling is done as specified in RFC 4213. We should add a paragraph highlighting some of the less-than-obvious impacts of RFC 4213: (1) Both MN and HA must configure a link-local addresses for the tunnel (Section 3.7) -- this spec needs to give the details of how this is done (e.g. if the construction given in Section 3.7 of RFC 4213 is used, we can skip DAD), and (2) Both MN and HA must support Neighbor Discovery over the tunnel (Section 3.8). |
2008-12-04
|
10 | Pasi Eronen | [Ballot Position Update] New position, Discuss, has been recorded by Pasi Eronen |
2008-12-04
|
10 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded by Jon Peterson |
2008-12-03
|
10 | Mark Townsley | [Ballot Position Update] New position, Yes, has been recorded by Mark Townsley |
2008-12-03
|
10 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu |
2008-12-03
|
10 | Tim Polk | [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk |
2008-12-03
|
10 | Tim Polk | [Ballot comment] This is an updated comment: Issue #1 is the new issue; Issue #2 has been addressed in email for the authors already. Issue … [Ballot comment] This is an updated comment: Issue #1 is the new issue; Issue #2 has been addressed in email for the authors already. Issue #1 The IPv6 Prefix Reply Extension is defined as a skippable extension. As I understand the protocol, this extension will only appear if the client included the IPv6 Prefix Request Extension in a previous message, so I would expect the client to always support this extension. In fact, if the client does not support the extension, it seems to be some kind of error condition. Is there an advantage to using a skippable extension for the prefix reply? Issue #2 The text in section 4.5, list item 2) apparently assumes that the code value in the registration reply header is set to an accept code, but this isn't stated. Perhaps it is obvious, given the text in 4.2, but it might bear repeating here. If the mobile node receives a registration reply header with a code value set to a reject code, would it also follow the procedures in list item 1)? |
2008-12-02
|
10 | Chris Newman | [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman |
2008-12-02
|
10 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley |
2008-12-02
|
10 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings |
2008-12-02
|
10 | Tim Polk | [Ballot comment] The text in section 4.5, list item 2) apparently assumes that the code value in the registration reply header is set to an … [Ballot comment] The text in section 4.5, list item 2) apparently assumes that the code value in the registration reply header is set to an accept code, but this isn't stated. Perhaps it is obvious, given the text in 4.2, but it might bear repeating here. If the mobile node receives a registration reply header with a code value set to a reject code, would it also follow the procedures in list item 1)? |
2008-12-01
|
10 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert |
2008-11-18
|
10 | Jari Arkko | State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Jari Arkko |
2008-11-18
|
08 | (System) | New version available: draft-ietf-mip4-dsmipv4-08.txt |
2008-11-11
|
10 | Samuel Weiler | Request for Last Call review by SECDIR Completed. Reviewer: Yaron Sheffer. |
2008-11-04
|
10 | (System) | State has been changed to Waiting for AD Go-Ahead from In Last Call by system |
2008-11-04
|
10 | Jari Arkko | Placed on agenda for telechat - 2008-12-04 by Jari Arkko |
2008-10-31
|
10 | Amanda Baber | IANA Last Call questions/comments: The IANA has reviewed draft-ietf-mip4-dsmipv4-07.txt, which is currently in Last Call, and has the following comments regarding its publication: IANA … IANA Last Call questions/comments: The IANA has reviewed draft-ietf-mip4-dsmipv4-07.txt, which is currently in Last Call, and has the following comments regarding its publication: IANA Has Questions: - In Action 1, the document does not specify whether the registration is from "Extensions appearing in Mobile IP control messages" or from " Mobile IP Extensions for ICMP Router Discovery messages". Can you verify that it is from the "Extensions appearing in Mobile IP control messages"? - in Action 2, the document does not specify a Registration Procedure for the Dual Stack (DSMIPv4) Extension subtypes registry. Can you verify that your intention was Expert Review? IESG Note: Expert Reviewer(s) Assignment(s) required Action 1: Upon approval of this document, the IANA will make the following assignments in the "Extensions appearing in Mobile IP control messages" registry at http://www.iana.org/assignments/mobileip-numbers Value Name Reference ----- ------------------------------------- --------- [tbd(128-255)] Dual Stack (DSMIPv4) Extension [RFC-mip4-dsmipv4-07] Action 2: Upon approval of this document, the IANA will create a new sub-registry in "Mobile IPv4 Numbers" called "Dual Stack (DSMIPv4) Extension subtypes" at http://www.iana.org/assignments/mobileip-numbers Reference: [RFC-mip4-dsmipv4-07] Registration Procedures: Expert Review Initial contents of this sub-registry will be: Code Name Reference ---- --------- -------------- 1 IPv6 Prefix Request [RFC-mip4-dsmipv4-07] 2 IPv6 Prefix Reply [RFC-mip4-dsmipv4-07] 3 IPv6 Tunneling Mode [RFC-mip4-dsmipv4-07] Action 3: Upon approval of this document, the IANA will create a new sub-registry called "IPv6 Prefix Reply Extension Codes" in "Mobile IPv4 Numbers" at http://www.iana.org/assignments/mobileip-numbers Reference: [RFC-mip4-dsmipv4-07] Registration Procedures: Expert Review Initial contents of this sub-registry will be: Code Description Reference ---- ------------------------------- -------------- 0 registration accepted, IPv6 to be tunneled to HoA [RFC-mip4-dsmipv4-07] 1 registration accepted, IPv6 to be tunneled to CoA [RFC-mip4-dsmipv4-07] 2-7 Available for Accept Codes [RFC-mip4-dsmipv4-07] 8 registration rejected, reason unspecified [RFC-mip4-dsmipv4-07] 9 registration rejected, administratively prohibited [RFC-mip4-dsmipv4-07] 10-255 Available for Reject Codes [RFC-mip4-dsmipv4-07] We understand the above to be the only IANA Actions for this document. |
2008-10-23
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2008-10-23
|
10 | Samuel Weiler | Request for Last Call review by SECDIR is assigned to Yaron Sheffer |
2008-10-21
|
10 | Amy Vezza | Last call sent |
2008-10-21
|
10 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2008-10-21
|
10 | Jari Arkko | State Changes to Last Call Requested from AD Evaluation::AD Followup by Jari Arkko |
2008-10-21
|
10 | Jari Arkko | Last Call was requested by Jari Arkko |
2008-10-21
|
10 | Jari Arkko | [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko |
2008-10-21
|
10 | Jari Arkko | Ballot has been issued by Jari Arkko |
2008-10-21
|
10 | Jari Arkko | Created "Approve" ballot |
2008-10-21
|
10 | (System) | Ballot writeup text was added |
2008-10-21
|
10 | (System) | Last call text was added |
2008-10-21
|
10 | (System) | Ballot approval text was added |
2008-10-21
|
10 | (System) | Sub state has been changed to AD Follow up from New Id Needed |
2008-10-21
|
07 | (System) | New version available: draft-ietf-mip4-dsmipv4-07.txt |
2008-08-21
|
10 | Jari Arkko | State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Jari Arkko |
2008-08-21
|
10 | Jari Arkko | I have reviewed this specification. It is in relatively good shape, but there are a number of issues that we should correct before moving forward. … I have reviewed this specification. It is in relatively good shape, but there are a number of issues that we should correct before moving forward. The biggest issues relate to: - completeness of the rules relating to address overlap - authorization rules for address allocation - use of proxy ND on both addresses and prefixes - interface ID construction rules In addition, I question the design decision to support addresses as well as prefixes. If your protocol supported only prefixes, it would be significantly simpler. Please find a number of issues and questions below. First the technical ones: > Prefix Length > > ... > > Indicates the prefix length of the prefix included in the Mobile > IPv6 Network Prefix field > > ... > > Mobile IPv6 Network Prefix > > A sixteen-byte field containing the Mobile IPv6 Network Prefix > > The following values are defined for use as a Code value in the above > extension > > ... > > 11 registration rejected, Duplicate Address Detection failed > If the IPv6 home address included in an IPv6 Prefix Request extension > is not an on-link IPv6 address with respect to the home agent's > current Prefix List or a prefix it is configured to serve, ... Having read the document this far, the request extension has a prefix, not an address. It is only later that you explain the prefix can actually be /128 as well. > When the IPv6 Prefix Request extension contains a /128 IPv6 address This can certainly be done, but I wonder about the need for this. If you did not have address support, you would: - get rid of DAD rules - get rid of ND proxying - avoid having to say something about SEND in security considerations section - simplify authorization and overlap rules - not have any multilink subnet-style issues - not introduce something that could easily be done by DHCP over a prefix - ... What is the rationale for including support for addresses? You will not be compatible with Mobile IPv6, so there is no need to attempt to match it. You are building a new extension to Mobile IPv4, and there is no fundamental reason to replicate its behaviour either. You do not intend to build a competitor for Mobile IPv6, so you do not need a long list of features. > Note that for IPv6 prefixes (rather than addresses), the home agent > does not have to perform Duplicate Address Detection but it MUST > check that allocated prefixes are not overlapping so that all > addresses under each allocated prefix are allocated only to a single > mobile node at any one time. Are other nodes allowed to take addresses from the prefixes allocated to mobile nodes? E.g., another mobile node requesting a /128, or if the prefix is on-link at the HA, some fixed node? I hope not. I would suggest a reformulation. For instance: Note that for IPv6 prefixes (rather than addresses), the home agent does not have to perform Duplicate Address Detection but it MUST make use a separate pool of prefixes that are only used for this purpose. These prefixes MUST NOT appear as on-link to any other node (e.g., via Router Advertisements). The home agent MUST check that allocated prefixes are not overlapping so that all addresses under each allocated prefix are allocated only to a single mobile node at any one time. In particular, a mobile node must not be able to request a /128 from a prefix allocated to another mobile node. > Dual stack home agents MUST use Proxy Neighbor Discovery [RFC4861] on > behalf of the nodes they serve. This seems wrong. You only need to proxy ND if the mobile nodes get just an address, not a prefix. > Packets addressed to the mobile node's IPv6 link-local address MUST > NOT be tunneled to the mobile node. Instead, these packets MUST be > discarded and the home agent SHOULD return an ICMPv6 Destination > Unreachable, Code 3, message to the packet's Source Address (unless > this Source Address is a multicast address). How does the home agent know what the mobile node's IPv6 link-local address is? > Multicast packets addressed to a multicast > address with a scope larger than link-local, but smaller than global > (e.g., site- local and organization-local [RFC4291], to which the > mobile node is subscribed, SHOULD NOT be tunneled to the mobile node. > Multicast packets addressed with a global scope, to which the mobile > node has successfully subscribed, MUST be tunneled to the mobile > node. I'm not sure I understand the rationale for making this distinction. I agree about not forwarding link-local traffic, but why the restriction on other scopes? > The only clarification required for the > purpose of this specification is that all MLD [RFC2710] or MLDv2 > [RFC3810] messages between the mobile node and the home agent MUST be > tunneled between the mobile node and the home agent, bypassing the > foreign agent. Does this change the home agent's decision to use a particular tunneling mode? Note that the home agent has no way to know if the mobile node will later send MLD messages. > A mobile node MAY include one or more IPv6 Prefix Request extensions > with the IPv6 Prefix field set to ::interface_identifier, where > interface_identifier is the unique layer 2 address of the client. > ... > > - the IPv6 prefix field set to PREFIX::interface_identifier and > the prefix length field set to 128. In this case an individual > IPv6 address is allocated to the mobile node. The use of a link layer address directly seems problematic. RFC 4291 has specific rules about how to use EUI-64 addresses (setting specific flags on and so on). Also, what about interface identifiers != 64 bits long? If you intend to keep the address functionality in the spec, the above rules have to be made more specific. > As defined in the security considerations section of RFC3344, ingress > filtering in the data path may prevent mobiles from using triangular > routing for their IPv6 communications even if the foreign agent used > supports the dual stack extensions defined in this specification. In > such cases reverse tunneling can be used to allow for effective > ingress filtering in intermediate routers without blocking IPv6 > traffic to reach its destination. The document is unclear about what foreign agents do about the IPv6 traffic. This should be more clearly specified. However, I do not think we should introduce the Mobile IPv4 triangular routing behavior in IPv6. This will be cause problems for ingress filtering, and would be something that we would have to take into account in many other products and specifications later on. > Security Considerations This section should talk about the authorization model to use an address/prefix. This model can be FCFS if that's what you want, but you should document its limitations. E.g., if you succeed in blocking a mobile node from re-registering, you can take over its address? Editorial: > ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Correct the above. > When IPv6 prefix and/or IPv6 tunneling mode extensions are used by > the mobile IP client, they MUST be placed after the registration > request header and before the mobile - home authentication extension > so they MUST be included in the computation of any authentication > extension. ... so that they will be included ...? I.e., their correct placement is the MUST and the rest just follows? Same issue in another paragraph a little further down in the same section. > In addition to that, the home agent SHOULD check that the source > address of the inner header is a register IPv4 or IPv6 home address > for this mobile node. s/register/registered/? |
2008-08-15
|
10 | Jari Arkko | State Changes to AD Evaluation from AD Evaluation::External Party by Jari Arkko |
2008-04-28
|
10 | Jari Arkko | State Changes to AD Evaluation::External Party from Publication Requested by Jari Arkko |
2008-04-28
|
10 | Jari Arkko | I will wait with this until DSMIPv6 is on the table as well. |
2008-02-19
|
10 | Cindy Morgan | PROTO STATEMENT: draft-ietf-mip4-dsmipv4-06 (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in … PROTO STATEMENT: draft-ietf-mip4-dsmipv4-06 (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? * Henrik Levkowetz, MIP4 co-chair * Reviewed, yes * Ready, yes. RFC-editor: please change "IPv6 packetm" to "IPv6 packet," in para. 10 of Section 4.3.2. (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? * Yes * No (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? * No (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. * No concerns * No IPR disclosures (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? * The WG last call was generally positive, but raised some issues. These have all been handled in version -06. (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.) * No threat of appeal or other discontent. (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? * Idnits check passed, plus manual verification as needed, including: - Network byte order - IANA considerations - Author Address - Meaningful Abstract - Meaningful Security Considerations - Not outdateable text - Protocol behaviour characteristics (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]. * Reference split OK (this is covered by 1.g) * No references to documents not ready for advancements * No downward refs (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? * IANA considerations verified (this is covered by 1.g) * All other items of 1.i verified (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? * Not applicable (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 * "This specification provides extensions to the Mobile IPv4 protocol, which allow a dual stack node to use both IPv4 and IPv6 home addresses, while moving between IPv4 and dual stack network attachment points." Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? * Nothing to note. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? * The protocol has been implemented by Flarion, and an internal implementation has also been made at IPunplugged. The shepherd does not have further knowledge of implementation plans (although he'd guess that Cisco has already implemented this, and if not, will shortly do so). |
2008-02-19
|
10 | Cindy Morgan | Draft Added by Cindy Morgan in state Publication Requested |
2008-02-13
|
06 | (System) | New version available: draft-ietf-mip4-dsmipv4-06.txt |
2007-10-04
|
05 | (System) | New version available: draft-ietf-mip4-dsmipv4-05.txt |
2007-09-24
|
04 | (System) | New version available: draft-ietf-mip4-dsmipv4-04.txt |
2007-08-07
|
03 | (System) | New version available: draft-ietf-mip4-dsmipv4-03.txt |
2007-05-01
|
02 | (System) | New version available: draft-ietf-mip4-dsmipv4-02.txt |
2006-12-29
|
01 | (System) | New version available: draft-ietf-mip4-dsmipv4-01.txt |
2006-08-15
|
00 | (System) | New version available: draft-ietf-mip4-dsmipv4-00.txt |