Skip to main content

WiMAX Forum / 3GPP2 Proxy Mobile IPv4
RFC 5563

Revision differences

Document history

Date Rev. By Action
2017-05-16
10 (System) Changed document authors from "Kent Leung" to "Kent Leung, Gopal Dommety, Kuntal Chowdhury, Parviz Yegani"
2015-10-14
10 (System) Notify list changed from kleung@cisco.com,mip4-chairs@ietf.org to mip4-chairs@ietf.org
2010-02-09
10 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2010-02-09
10 Amy Vezza [Note]: 'RFC 5563' added by Amy Vezza
2010-02-08
10 (System) RFC published
2008-12-08
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2008-12-05
10 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2008-12-05
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2008-12-05
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2008-12-05
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2008-12-01
10 (System) New version available: draft-leung-mip4-proxy-mode-10.txt
2008-11-05
10 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2008-10-03
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2008-10-03
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2008-10-02
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2008-09-22
10 (System) IANA Action state changed to In Progress
2008-09-15
10 Amy Vezza IESG state changed to Approved-announcement sent
2008-09-15
10 Amy Vezza IESG has approved the document
2008-09-15
10 Amy Vezza Closed "Approve" ballot
2008-09-12
10 (System) Removed from agenda for telechat - 2008-09-11
2008-09-11
10 Amy Vezza State Changes to Approved-announcement to be sent from IESG Evaluation by Amy Vezza
2008-09-11
10 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2008-09-11
10 David Ward [Ballot Position Update] New position, No Objection, has been recorded by David Ward
2008-09-11
10 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2008-09-11
10 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2008-09-11
10 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2008-09-11
10 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2008-09-10
10 Amanda Baber
IANA Evaluation comments:

IANA has questions for the authors:

- in Section 5.1, do you want a registry for the Authentication Methods?
- in Section …
IANA Evaluation comments:

IANA has questions for the authors:

- in Section 5.1, do you want a registry for the Authentication Methods?
- in Section 5.3, do you want a registry for the Device ID Type?
- in Section 5.4, do you want a registry for the Subscriber ID Type?
- in Section 5.5, do you want a registry for the Access Technology Type?


Action 1:

Upon approval of this document, the IANA will make the following
changes in the "Extensions appearing in Mobile IP control
messages" registry at
http://www.iana.org/assignments/mobileip-numbers

OLD:

Value Name Reference
------- ---------------------------------- ---------
47 PMIPv4 Non-skippable Extension
[draft-leung-mip4-proxy-mode-05.txt]
...
147 PMIPv4 Skippable Extension
[draft-leung-mip4-proxy-mode-05.txt]

NEW:

Value Name Reference
------- ---------------------------------- ---------
47 PMIPv4 Non-skippable Extension
[RFC-leung-mip4-proxy-mode-09]
...
147 PMIPv4 Skippable Extension
[RFC-leung-mip4-proxy-mode-09]


Action 2:

Upon approval of this document, the IANA will create the
following new sub-registry at
http://www.iana.org/assignments/mobileip-numbers

Registry Name: PMIPv4 Non-skippable Extension
Registration Procedures: Expert Review
Initial contents of this sub-registry will be:

Subtype
Value Name Reference
------- ---------------------------------------- ---------
1 PMIPv4 Per-Node Authentication Method
[RFC-leung-mip4-proxy-mode-09]


Action 3:

Upon approval of this document, the IANA will create the
following sub-registry at
http://www.iana.org/assignments/mobileip-numbers

Registry Name: PMIPv4 Skippable Extension
Registration Procedures: Expert Review
Initial contents of this sub-registry will be:

Subtype
Value Name Reference
------- ----------------------------------------- ---------
1 PMIPv4 Interface ID
[RFC-leung-mip4-proxy-mode-09]
2 PMIPv4 Device ID
[RFC-leung-mip4-proxy-mode-09]
3 PMIPv4 Subscriber ID
[RFC-leung-mip4-proxy-mode-09]
4 Access Technology Type
[RFC-leung-mip4-proxy-mode-09]


Action 4:

Upon approval of this document, the IANA will make the following
assignments in the "Code Values for Mobile IP Registration Reply
Messages" registry at
http://www.iana.org/assignments/mobileip-numbers


Registration denied by the home agent:

TBD PMIP_UNSUPPORTED [RFC-leung-mip4-proxy-mode-09]
TBD PMIP_DISALLOWED [RFC-leung-mip4-proxy-mode-09]

We understand the above to be the only IANA Actions for this
document.
2008-09-10
10 Ron Bonica [Ballot Position Update] New position, No Objection, has been recorded by Ron Bonica
2008-09-10
10 Pasi Eronen [Ballot Position Update] New position, No Objection, has been recorded by Pasi Eronen
2008-09-08
10 Chris Newman [Ballot Position Update] New position, No Objection, has been recorded by Chris Newman
2008-09-05
10 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2008-09-04
10 Jari Arkko authors confirm that they are willing to do the three changes
2008-09-02
10 Jari Arkko
[Ballot comment]
Three of the comments below are blocking (process issues and the EAP
keying framework issue) in the sense that I would like to …
[Ballot comment]
Three of the comments below are blocking (process issues and the EAP
keying framework issue) in the sense that I would like to see them
resolved before the IESG approves this spec according to RFC 3932
criteria. Given the small importance of those three issues, I am
assuming that the authors are willing to do this.

There is a fair number of other comments, which are not blocking
but could affect interoperability, correctness of behaviour, or
clarity of the specification. I am hoping that the authors are
willing to revise the specification one more time in order to
address these.

Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit the other
document to the RFC Editor as well, get MIP4 WG to publish the GRE
keying spec, or reword the text to make clear that GRE keying is not
a normative part of this spec.

Section 4.1.1 Step 6 claims that at this point the host has an
address and DNS config. However, you did not mention earlier
in the DHCP or IPCP cases that the DNS configs are exchanged;
the claim comes out of the blue for the reader. Perhaps you
could add text to the earlier steps.

Section 4.3 explanation of IPsec usage is sketchy. Please
provide a complete explanation of how IPsec is used, what
policies will match on, etc. See draft-bellovin-useipsec.

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.
Please make it clear that RFC 4436 can be employed (even if some
existing networks might use ICMP). The RFC 4436 reference should also
go into Section 4.1.3.

Section 10 mentions that the relevant keys will be "derived by the
EAP keying framework". This seems incorrect in a number of ways.
First, EAP keying framework (RFC 5247) is not a mechanism that
can be applied, it is an explanation of the properties and
requirements for the security of EAP keys. Perhaps saying
something along the lines of "... derived from EAP authentication
as specified in [WIMAX-DOC]" would be better. This resolves
the issue for this document, but really hope that the Wimax
specification employs MSK or draft-ietf-hokey-emsk and does not
use EMSK directly.

There is no discussion of MTU issues in the document at all. Please
add such a discussion. See RFC 5213 for an example (a different
example, given that MTU treatment in IPv6 is different).

There is no discussion of the requirements for the identification of
a mobile node. Compare with RFC 5213.

There is no discussion of the implications of using Mobile IPv4
as defined and Proxy Mobile IPv4 for the same nodes. Perhaps this
should be raised as an issue, declared something not supported,
or properly explained. It seems clear that per-MN security would
be hard to support in any proper way, for instance. Wouldn't that
require sharing the MN - HA secret with FAs as well?

I understand the behaviour of this spec over Ethernet-like interfaces.
IP stacks attempt to verify that their IP address is still valid.
However, if you run this over PPP, bringing down the previous PPP
connection and creating a new one would appear to cause the host
to lose the IP address (and consequently, all ongoing sessions).
There is no "confirm my address is valid" operation in PPP.

The document does not at all discuss the role of the various
identifiers (interface ID, device ID, subscriber ID, authentication
NAI) and the access technology type. Note that RFC 5213 includes
similar identifiers, but spends an extremely big part of the
document in explaining what kind of logic rules are used to
decide the behaviour of the PMIP nodes when faced with different
situations. Is this not needed in PMIPv4 at all? Or is the
document underspecified? Please clarify/extend the specification.
In particular, it is unclear what happens when hosts have
multiple interfaces. Note that RFC 5213 was built to be safe
in these situations, is PMIPv4 safe? The document is silent
on this and I cannot tell, but I suspect that the same
issues apply.

Section 3 claims IPv6 will work with PMIPv4 merely by the
use of PMIPv4 and DSMIPv4 together. I find this hard to
believe. To cite two examples where additional behavior
might be needed: similar to RFC 5213, wouldn't MTU changes
in the tunnel have to result in sending RAs with changed
MTU options? And what about carrying the link-local address
of the router? Or maybe that does not apply given that
PMIPv4 supports only L2 LMAs? In any case, the document
is too silent on this.

Process issues:

For full disclosure, I think it would be useful to mention
somewhere that there exists an IETF standard proxy mobile,
RFC 5213.

Section 3 says "In addition, the solution leverages standardized
specification and highly available implementations." This could
be mis-interpreted as PMIPv4 being a standard. I would like to see
this rewritten, e.g., as "In addition, while this specification
and Proxy Mobile IPv4 are not standards, they employ a standard,
Mobile IPv4. Implementations of Mobile IPv4 can be re-used at
least to an extent."

Editorial:

The document lacks separate sections for Informative/Normative
references.

There are too long lines in the document.

Weird indentation between first and second paragraphs of Section 2.

Reference [1] does not exist.

References 3011 and 3519 are unused.

No information found for draft-yegani-gre-key - is the name correct?

Obsoleted documents referenced: 1331, 1334, 2401, 2434.

The last sentence of the first paragraph in Section 4.1.4 does not read well.
2008-09-02
10 Jari Arkko
[Ballot comment]
Two of the comments below are blocking (process issue and the EAP
keying framework issue) in the sense that I would like to …
[Ballot comment]
Two of the comments below are blocking (process issue and the EAP
keying framework issue) in the sense that I would like to see them
resolved before the IESG approves this spec according to RFC 3932
criteria. Given the small importance of those two issues, I am
assuming that the authors are willing to do this.

There is a fair number of other comments, which are not blocking
but could affect interoperability, correctness of behaviour, or
clarity of the specification. I am hoping that the authors are
willing to revise the specification one more time in order to
address these.

Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit the other
document to the RFC Editor as well, get MIP4 WG to publish the GRE
keying spec, or reword the text to make clear that GRE keying is not
a normative part of this spec.

Section 4.1.1 Step 6 claims that at this point the host has an
address and DNS config. However, you did not mention earlier
in the DHCP or IPCP cases that the DNS configs are exchanged;
the claim comes out of the blue for the reader. Perhaps you
could add text to the earlier steps.

Section 4.3 explanation of IPsec usage is sketchy. Please
provide a complete explanation of how IPsec is used, what
policies will match on, etc. See draft-bellovin-useipsec.

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.
Please make it clear that RFC 4436 can be employed (even if some
existing networks might use ICMP). The RFC 4436 reference should also
go into Section 4.1.3.

Section 10 mentions that the relevant keys will be "derived by the
EAP keying framework". This seems incorrect in a number of ways.
First, EAP keying framework (RFC 5247) is not a mechanism that
can be applied, it is an explanation of the properties and
requirements for the security of EAP keys. Perhaps saying
something along the lines of "... derived from EAP authentication
as specified in [WIMAX-DOC]" would be better. This resolves
the issue for this document, but really hope that the Wimax
specification employs MSK or draft-ietf-hokey-emsk and does not
use EMSK directly.

There is no discussion of MTU issues in the document at all. Please
add such a discussion. See RFC 5213 for an example (a different
example, given that MTU treatment in IPv6 is different).

There is no discussion of the requirements for the identification of
a mobile node. Compare with RFC 5213.

There is no discussion of the implications of using Mobile IPv4
as defined and Proxy Mobile IPv4 for the same nodes. Perhaps this
should be raised as an issue, declared something not supported,
or properly explained. It seems clear that per-MN security would
be hard to support in any proper way, for instance. Wouldn't that
require sharing the MN - HA secret with FAs as well?

I understand the behaviour of this spec over Ethernet-like interfaces.
IP stacks attempt to verify that their IP address is still valid.
However, if you run this over PPP, bringing down the previous PPP
connection and creating a new one would appear to cause the host
to lose the IP address (and consequently, all ongoing sessions).
There is no "confirm my address is valid" operation in PPP.

The document does not at all discuss the role of the various
identifiers (interface ID, device ID, subscriber ID, authentication
NAI) and the access technology type. Note that RFC 5213 includes
similar identifiers, but spends an extremely big part of the
document in explaining what kind of logic rules are used to
decide the behaviour of the PMIP nodes when faced with different
situations. Is this not needed in PMIPv4 at all? Or is the
document underspecified? Please clarify/extend the specification.
In particular, it is unclear what happens when hosts have
multiple interfaces. Note that RFC 5213 was built to be safe
in these situations, is PMIPv4 safe? The document is silent
on this and I cannot tell, but I suspect that the same
issues apply.

Section 3 claims IPv6 will work with PMIPv4 merely by the
use of PMIPv4 and DSMIPv4 together. I find this hard to
believe. To cite two examples where additional behavior
might be needed: similar to RFC 5213, wouldn't MTU changes
in the tunnel have to result in sending RAs with changed
MTU options? And what about carrying the link-local address
of the router? Or maybe that does not apply given that
PMIPv4 supports only L2 LMAs? In any case, the document
is too silent on this.

Process issues:

Section 3 says "In addition, the solution leverages standardized
specification and highly available implementations." This could
be mis-interpreted as PMIPv4 being a standard. I would like to see
this rewritten, e.g., as "In addition, while this specification
and Proxy Mobile IPv4 are not standards, they employ a standard,
Mobile IPv4. Implementations of Mobile IPv4 can be re-used at
least to an extent."

Editorial:

The document lacks separate sections for Informative/Normative
references.

There are too long lines in the document.

Weird indentation between first and second paragraphs of Section 2.

Reference [1] does not exist.

References 3011 and 3519 are unused.

No information found for draft-yegani-gre-key - is the name correct?

Obsoleted documents referenced: 1331, 1334, 2401, 2434.

The last sentence of the first paragraph in Section 4.1.4 does not read well.
2008-09-02
10 Jari Arkko
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit …
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit the other
document to the RFC Editor as well, get MIP4 WG to publish the GRE
keying spec, or reword the text to make clear that GRE keying is not
a normative part of this spec.

Section 4.1.1 Step 6 claims that at this point the host has an
address and DNS config. However, you did not mention earlier
in the DHCP or IPCP cases that the DNS configs are exchanged;
the claim comes out of the blue for the reader. Perhaps you
could add text to the earlier steps.

Section 4.3 explanation of IPsec usage is sketchy. Please
provide a complete explanation of how IPsec is used, what
policies will match on, etc. See draft-bellovin-useipsec.

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.
Please make it clear that RFC 4436 can be employed (even if some
existing networks might use ICMP). The RFC 4436 reference should also
go into Section 4.1.3.

Section 10 mentions that the relevant keys will be "derived by the
EAP keying framework". This seems incorrect in a number of ways.
First, EAP keying framework (RFC 5247) is not a mechanism that
can be applied, it is an explanation of the properties and
requirements for the security of EAP keys. Perhaps saying
something along the lines of "... derived from EAP authentication
as specified in [WIMAX-DOC]" would be better. This resolves
the issue for this document, but really hope that the Wimax
specification employs MSK or draft-ietf-hokey-emsk and does not
use EMSK directly.

There is no discussion of MTU issues in the document at all. Please
add such a discussion. See RFC 5213 for an example (a different
example, given that MTU treatment in IPv6 is different).

There is no discussion of the requirements for the identification of
a mobile node. Compare with RFC 5213.

There is no discussion of the implications of using Mobile IPv4
as defined and Proxy Mobile IPv4 for the same nodes. Perhaps this
should be raised as an issue, declared something not supported,
or properly explained. It seems clear that per-MN security would
be hard to support in any proper way, for instance. Wouldn't that
require sharing the MN - HA secret with FAs as well?

I understand the behaviour of this spec over Ethernet-like interfaces.
IP stacks attempt to verify that their IP address is still valid.
However, if you run this over PPP, bringing down the previous PPP
connection and creating a new one would appear to cause the host
to lose the IP address (and consequently, all ongoing sessions).
There is no "confirm my address is valid" operation in PPP.

Process issues:

Section 3 says "In addition, the solution leverages standardized
specification and highly available implementations." This could
be mis-interpreted as PMIPv4 being a standard. I would like to see
this rewritten, e.g., as "In addition, while this specification
and Proxy Mobile IPv4 are not standards, they employ a standard,
Mobile IPv4. Implementations of Mobile IPv4 can be re-used at
least to an extent."

Editorial:

The document lacks separate sections for Informative/Normative
references.

There are too long lines in the document.

Weird indentation between first and second paragraphs of Section 2.

Reference [1] does not exist.

References 3011 and 3519 are unused.

No information found for draft-yegani-gre-key - is the name correct?

Obsoleted documents referenced: 1331, 1334, 2401, 2434.

The last sentence of the first paragraph in Section 4.1.4 does not read well.
2008-09-02
10 Jari Arkko
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit …
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit the other
document to the RFC Editor as well, get MIP4 WG to publish the GRE
keying spec, or reword the text to make clear that GRE keying is not
a normative part of this spec.

Section 4.1.1 Step 6 claims that at this point the host has an
address and DNS config. However, you did not mention earlier
in the DHCP or IPCP cases that the DNS configs are exchanged;
the claim comes out of the blue for the reader. Perhaps you
could add text to the earlier steps.

Section 4.3 explanation of IPsec usage is sketchy. Please
provide a complete explanation of how IPsec is used, what
policies will match on, etc. See draft-bellovin-useipsec.

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.
Please make it clear that RFC 4436 can be employed (even if some
existing networks might use ICMP). The RFC 4436 reference should also
go into Section 4.1.3.

There is no discussion of MTU issues in the document at all. Please
add such a discussion. See RFC 5213 for an example (a different
example, given that MTU treatment in IPv6 is different).

There is no discussion of the requirements for the identification of
a mobile node. Compare with RFC 5213.

There is no discussion of the implications of using Mobile IPv4
as defined and Proxy Mobile IPv4 for the same nodes. Perhaps this
should be raised as an issue, declared something not supported,
or properly explained. It seems clear that per-MN security would
be hard to support in any proper way, for instance. Wouldn't that
require sharing the MN - HA secret with FAs as well?

I understand the behaviour of this spec over Ethernet-like interfaces.
IP stacks attempt to verify that their IP address is still valid.
However, if you run this over PPP, bringing down the previous PPP
connection and creating a new one would appear to cause the host
to lose the IP address (and consequently, all ongoing sessions).
There is no "confirm my address is valid" operation in PPP.

Process issues:

Section 3 says "In addition, the solution leverages standardized
specification and highly available implementations." This could
be mis-interpreted as PMIPv4 being a standard. I would like to see
this rewritten, e.g., as "In addition, while this specification
and Proxy Mobile IPv4 are not standards, they employ a standard,
Mobile IPv4. Implementations of Mobile IPv4 can be re-used at
least to an extent."

Editorial:

The document lacks separate sections for Informative/Normative
references.

There are too long lines in the document.

Weird indentation between first and second paragraphs of Section 2.

Reference [1] does not exist.

References 3011 and 3519 are unused.

No information found for draft-yegani-gre-key - is the name correct?

Obsoleted documents referenced: 1331, 1334, 2401, 2434.

The last sentence of the first paragraph in Section 4.1.4 does not read well.
2008-09-02
10 Jari Arkko
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit …
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit the other
document to the RFC Editor as well, get MIP4 WG to publish the GRE
keying spec, or reword the text to make clear that GRE keying is not
a normative part of this spec.

Section 4.1.1 Step 6 claims that at this point the host has an
address and DNS config. However, you did not mention earlier
in the DHCP or IPCP cases that the DNS configs are exchanged;
the claim comes out of the blue for the reader. Perhaps you
could add text to the earlier steps.

Section 4.3 explanation of IPsec usage is sketchy. Please
provide a complete explanation of how IPsec is used, what
policies will match on, etc. See draft-bellovin-useipsec.

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.
Please make it clear that RFC 4436 can be employed (even if some
existing networks might use ICMP). The RFC 4436 reference should also
go into Section 4.1.3.

There is no discussion of MTU issues in the document at all. Please
add such a discussion. See RFC 5213 for an example (a different
example, given that MTU treatment in IPv6 is different).

There is no discussion of the requirements for the identification of
a mobile node. Compare with RFC 5213.

There is no discussion of the implications of using Mobile IPv4
as defined and Proxy Mobile IPv4 for the same nodes. Perhaps this
should be raised as an issue, declared something not supported,
or properly explained. It seems clear that per-MN security would
be hard to support in any proper way, for instance. Wouldn't that
require sharing the MN - HA secret with FAs as well?

Process issues:

Section 3 says "In addition, the solution leverages standardized
specification and highly available implementations." This could
be mis-interpreted as PMIPv4 being a standard. I would like to see
this rewritten, e.g., as "In addition, while this specification
and Proxy Mobile IPv4 are not standards, they employ a standard,
Mobile IPv4. Implementations of Mobile IPv4 can be re-used at
least to an extent."

Editorial:

The document lacks separate sections for Informative/Normative
references.

There are too long lines in the document.

Weird indentation between first and second paragraphs of Section 2.

Reference [1] does not exist.

References 3011 and 3519 are unused.

No information found for draft-yegani-gre-key - is the name correct?

Obsoleted documents referenced: 1331, 1334, 2401, 2434.

The last sentence of the first paragraph in Section 4.1.4 does not read well.
2008-09-02
10 Jari Arkko
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit …
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit the other
document to the RFC Editor as well, get MIP4 WG to publish the GRE
keying spec, or reword the text to make clear that GRE keying is not
a normative part of this spec.

Section 4.1.1 Step 6 claims that at this point the host has an
address and DNS config. However, you did not mention earlier
in the DHCP or IPCP cases that the DNS configs are exchanged;
the claim comes out of the blue for the reader. Perhaps you
could add text to the earlier steps.

Section 4.3 explanation of IPsec usage is sketchy. Please
provide a complete explanation of how IPsec is used, what
policies will match on, etc. See draft-bellovin-useipsec.

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.
Please make it clear that RFC 4436 can be employed (even if some
existing networks might use ICMP). The RFC 4436 reference should also
go into Section 4.1.3.

There is no discussion of MTU issues in the document at all. Please
add such a discussion. See RFC 5213 for an example (a different
example, given that MTU treatment in IPv6 is different).

There is no discussion of the requirements for the identification of
a mobile node. Compare with RFC 5213.

There is no discussion of the implications of using Mobile IPv4
as defined and Proxy Mobile IPv4 for the same nodes. Perhaps this
should be raised as an issue, declared something not supported,
or properly explained. It seems clear that per-MN security would
be hard to support in any proper way, for instance. Wouldn't that
require sharing the MN - HA secret with FAs as well?

Process issues:

Section 3 says "In addition, the solution leverages standardized
specification and highly available implementations." This could
be mis-interpreted as PMIPv4 being a standard. I would like to see
this rewritten, e.g., as "In addition, while this specification
and Proxy Mobile IPv4 are not standards, they employ a standard,
Mobile IPv4. Implementations of Mobile IPv4 can be re-used at
least to an extent."

Editorial:

The document lacks separate sections for Informative/Normative
references.

There are too long lines in the document.

Weird indentation between first and second paragraphs of Section 2.

Reference [1] does not exist.

References 3011 and 3519 are unused.

No information found for draft-yegani-gre-key - is the name correct?

Obsoleted documents referenced: 1331, 1334, 2401, 2434.

The last sentence of the first paragraph in Section 4.1.4 does not read well.
2008-09-02
10 Jari Arkko
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit …
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit the other
document to the RFC Editor as well, get MIP4 WG to publish the GRE
keying spec, or reword the text to make clear that GRE keying is not
a normative part of this spec.

Section 4.1.1 Step 6 claims that at this point the host has an
address and DNS config. However, you did not mention earlier
in the DHCP or IPCP cases that the DNS configs are exchanged;
the claim comes out of the blue for the reader. Perhaps you
could add text to the earlier steps.

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.
Please make it clear that RFC 4436 can be employed (even if some
existing networks might use ICMP). The RFC 4436 reference should also
go into Section 4.1.3.

There is no discussion of MTU issues in the document at all. Please
add such a discussion. See RFC 5213 for an example (a different
example, given that MTU treatment in IPv6 is different).

There is no discussion of the requirements for the identification of
a mobile node. Compare with RFC 5213.

There is no discussion of the implications of using Mobile IPv4
as defined and Proxy Mobile IPv4 for the same nodes. Perhaps this
should be raised as an issue, declared something not supported,
or properly explained.

Process issues:

Section 3 says "In addition, the solution leverages standardized
specification and highly available implementations." This could
be mis-interpreted as PMIPv4 being a standard. I would like to see
this rewritten, e.g., as "In addition, while this specification
and Proxy Mobile IPv4 are not standards, they employ a standard,
Mobile IPv4. Implementations of Mobile IPv4 can be re-used at
least to an extent."

Editorial:

The document lacks separate sections for Informative/Normative
references.

There are too long lines in the document.

Weird indentation between first and second paragraphs of Section 2.

Reference [1] does not exist.

References 3011 and 3519 are unused.

No information found for draft-yegani-gre-key - is the name correct?

Obsoleted documents referenced: 1331, 1334, 2401, 2434.

The last sentence of the first paragraph in Section 4.1.4 does not read well.
2008-09-02
10 Jari Arkko
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit …
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit the other
document to the RFC Editor as well, get MIP4 WG to publish the GRE
keying spec, or reword the text to make clear that GRE keying is not
a normative part of this spec.

Section 4.1.1 Step 6 claims that at this point the host has an
address and DNS config. However, you did not mention earlier
in the DHCP or IPCP cases that the DNS configs are exchanged;
the claim comes out of the blue for the reader. Perhaps you
could add text to the earlier steps.

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.
Please make it clear that RFC 4436 can be employed (even if some
existing networks might use ICMP). The RFC 4436 reference should also
go into Section 4.1.3.

There is no discussion of MTU issues in the document at all. Please
add such a discussion. See RFC 5213 for an example (a different
example, given that MTU treatment in IPv6 is different).

There is no discussion of the requirements for the identification of
a mobile node. Compare with RFC 5213.

Process issues:

Section 3 says "In addition, the solution leverages standardized
specification and highly available implementations." This could
be mis-interpreted as PMIPv4 being a standard. I would like to see
this rewritten, e.g., as "In addition, while this specification
and Proxy Mobile IPv4 are not standards, they employ a standard,
Mobile IPv4. Implementations of Mobile IPv4 can be re-used at
least to an extent."

Editorial:

The document lacks separate sections for Informative/Normative
references.

There are too long lines in the document.

Weird indentation between first and second paragraphs of Section 2.

Reference [1] does not exist.

References 3011 and 3519 are unused.

No information found for draft-yegani-gre-key - is the name correct?

Obsoleted documents referenced: 1331, 1334, 2401, 2434.

The last sentence of the first paragraph in Section 4.1.4 does not read well.
2008-09-02
10 Jari Arkko
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit …
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit the other
document to the RFC Editor as well, or reword to make it clear that
GRE keying is not a normative part of this spec.

Section 4.1.1 Step 6 claims that at this point the host has an
address and DNS config. However, you did not mention earlier
in the DHCP or IPCP cases that the DNS configs are exchanged;
the claim comes out of the blue for the reader. Perhaps you
could add text to the earlier steps.

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.
Please make it clear that RFC 4436 can be employed (even if some
existing networks might use ICMP). The RFC 4436 reference should also
go into Section 4.1.3.

There is no discussion of MTU issues in the document at all. Please
add such a discussion. See RFC 5213 for an example (a different
example, given that MTU treatment in IPv6 is different).

There is no discussion of the requirements for the identification of
a mobile node. Compare with RFC 5213.

Process issues:

Section 3 says "In addition, the solution leverages standardized
specification and highly available implementations." This could
be mis-interpreted as PMIPv4 being a standard. I would like to see
this rewritten, e.g., as "In addition, while this specification
and Proxy Mobile IPv4 are not standards, they employ a standard,
Mobile IPv4. Implementations of Mobile IPv4 can be re-used at
least to an extent."

Editorial:

The document lacks separate sections for Informative/Normative
references.

There are too long lines in the document.

Weird indentation between first and second paragraphs of Section 2.

Reference [1] does not exist.

References 3011 and 3519 are unused.

No information found for draft-yegani-gre-key - is the name correct?

Obsoleted documents referenced: 1331, 1334, 2401, 2434.
2008-09-02
10 Jari Arkko
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit …
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit the other
document to the RFC Editor as well, or reword to make it clear that
GRE keying is not a normative part of this spec.

Section 4.1.1 Step 6 claims that at this point the host has an
address and DNS config. However, you did not mention earlier
in the DHCP or IPCP cases that the DNS configs are exchanged;
the claim comes out of the blue for the reader. Perhaps you
could add text to the earlier steps.

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.
Please make it clear that RFC 4436 can be employed (even if some
existing networks might use ICMP).

There is no discussion of MTU issues in the document at all. Please
add such a discussion. See RFC 5213 for an example (a different
example, given that MTU treatment in IPv6 is different).

There is no discussion of the requirements for the identification of
a mobile node. Compare with RFC 5213.

Process issues:

Section 3 says "In addition, the solution leverages standardized
specification and highly available implementations." This could
be mis-interpreted as PMIPv4 being a standard. I would like to see
this rewritten, e.g., as "In addition, while this specification
and Proxy Mobile IPv4 are not standards, they employ a standard,
Mobile IPv4. Implementations of Mobile IPv4 can be re-used at
least to an extent."

Editorial:

The document lacks separate sections for Informative/Normative
references.

There are too long lines in the document.

Weird indentation between first and second paragraphs of Section 2.

Reference [1] does not exist.

References 3011 and 3519 are unused.

No information found for draft-yegani-gre-key - is the name correct?

Obsoleted documents referenced: 1331, 1334, 2401, 2434.
2008-09-02
10 Jari Arkko
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit …
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit the other
document to the RFC Editor as well, or reword to make it clear that
GRE keying is not a normative part of this spec.

Section 4.1.1 Step 6 claims that at this point the host has an
address and DNS config. However, you did not mention earlier
in the DHCP or IPCP cases that the DNS configs are exchanged;
the claim comes out of the blue for the reader. Perhaps you
could add text to the earlier steps.

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.
Please make it clear that RFC 4436 can be employed (even if some
existing networks might use ICMP).

There is no discussion of MTU issues in the document at all. Please
add such a discussion.

Process issues:

Section 3 says "In addition, the solution leverages standardized
specification and highly available implementations." This could
be mis-interpreted as PMIPv4 being a standard. I would like to see
this rewritten, e.g., as "In addition, while this specification
and Proxy Mobile IPv4 are not standards, they employ a standard,
Mobile IPv4. Implementations of Mobile IPv4 can be re-used at
least to an extent."

Editorial:

The document lacks separate sections for Informative/Normative
references.

There are too long lines in the document.

Weird indentation between first and second paragraphs of Section 2.

Reference [1] does not exist.

References 3011 and 3519 are unused.

No information found for draft-yegani-gre-key - is the name correct?

Obsoleted documents referenced: 1331, 1334, 2401, 2434.
2008-09-02
10 Jari Arkko
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit …
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit the other
document to the RFC Editor as well, or reword to make it clear that
GRE keying is not a normative part of this spec.

Section 4.1.1 Step 6 claims that at this point the host has an
address and DNS config. However, you did not mention earlier
in the DHCP or IPCP cases that the DNS configs are exchanged;
the claim comes out of the blue for the reader. Perhaps you
could add text to the earlier steps.

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.
Please make it clear that RFC 4436 can be employed (even if some
existing networks might use ICMP).

Process issues:

Section 3 says "In addition, the solution leverages standardized
specification and highly available implementations." This could
be mis-interpreted as PMIPv4 being a standard. I would like to see
this rewritten, e.g., as "In addition, while this specification
and Proxy Mobile IPv4 are not standards, they employ a standard,
Mobile IPv4. Implementations of Mobile IPv4 can be re-used at
least to an extent."

Editorial:

The document lacks separate sections for Informative/Normative
references.

There are too long lines in the document.

Weird indentation between first and second paragraphs of Section 2.

Reference [1] does not exist.

References 3011 and 3519 are unused.

No information found for draft-yegani-gre-key - is the name correct?

Obsoleted documents referenced: 1331, 1334, 2401, 2434.
2008-09-02
10 Jari Arkko
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit …
[Ballot comment]
Technical:

Section 4.1.1 refers to an expired ID about the usage of GRE keying,
in a manner that appears normative. Please remove, submit the other
document to the RFC Editor as well, or reword to make it clear that
GRE keying is not a normative part of this spec.

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.
Please make it clear that RFC 4436 can be employed (even if some
existing networks might use ICMP).

Process issues:

Section 3 says "In addition, the solution leverages standardized
specification and highly available implementations." This could
be mis-interpreted as PMIPv4 being a standard. I would like to see
this rewritten, e.g., as "In addition, while this specification
and Proxy Mobile IPv4 are not standards, they employ a standard,
Mobile IPv4. Implementations of Mobile IPv4 can be re-used at
least to an extent."

Editorial:

The document lacks separate sections for Informative/Normative
references.

There are too long lines in the document.

Weird indentation between first and second paragraphs of Section 2.

Reference [1] does not exist.

References 3011 and 3519 are unused.

No information found for draft-yegani-gre-key - is the name correct?

Obsoleted documents referenced: 1331, 1334, 2401, 2434.
2008-09-02
10 Jari Arkko
[Ballot comment]
Technical:

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436 …
[Ballot comment]
Technical:

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.

Process issues:

Section 3 says "In addition, the solution leverages standardized
specification and highly available implementations." This could
be mis-interpreted as PMIPv4 being a standard. I would like to see
this rewritten, e.g., as "In addition, while this specification
and Proxy Mobile IPv4 are not standards, they employ a standard,
Mobile IPv4. Implementations of Mobile IPv4 can be re-used at
least to an extent."

Editorial:

The document lacks separate sections for Informative/Normative
references.

There are too long lines in the document.

Weird indentation between first and second paragraphs of Section 2.

Reference [1] does not exist.

References 3011 and 3519 are unused.

No information found for draft-yegani-gre-key - is the name correct?

Obsoleted documents referenced: 1331, 1334, 2401, 2434.
2008-09-02
10 Jari Arkko
[Ballot comment]
Technical:

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436 …
[Ballot comment]
Technical:

Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.

Editorial:

The document lacks separate sections for Informative/Normative
references.

There are too long lines in the document.

Weird indentation between first and second paragraphs of Section 2.

Reference [1] does not exist.

References 3011 and 3519 are unused.

No information found for draft-yegani-gre-key - is the name correct?

Obsoleted documents referenced: 1331, 1334, 2401, 2434.
2008-09-01
10 Jari Arkko [Ballot comment]
Section 6.2 appears to propose an ICMP-based movement detection scheme
which is likely inferior to the standard schemed defined in RFC 4436.
2008-09-01
10 Jari Arkko Intended Status has been changed to Informational from None
2008-09-01
10 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded for Jari Arkko
2008-09-01
10 Jari Arkko Ballot has been issued by Jari Arkko
2008-09-01
10 Jari Arkko Created "Approve" ballot
2008-09-01
10 (System) Ballot writeup text was added
2008-09-01
10 (System) Last call text was added
2008-09-01
10 (System) Ballot approval text was added
2008-09-01
10 Jari Arkko Placed on the next telechat agenda.
2008-09-01
10 Jari Arkko Placed on agenda for telechat - 2008-09-11 by Jari Arkko
2008-09-01
10 Jari Arkko State Changes to IESG Evaluation from Publication Requested by Jari Arkko
2008-09-01
10 Jari Arkko The authors have finally submitted their work via the RFC Editor. Sending this forward to the rest of the IESG.
2008-09-01
10 Jari Arkko Note field has been cleared by Jari Arkko
2008-08-29
10 Cindy Morgan State Changes to Publication Requested from AD is watching by Cindy Morgan
2008-08-29
10 Cindy Morgan
IESG,

This document was submitted to the RFC Editor to be published as an
Informational Independent Submission:
draft-leung-mip4-proxy-mode-09.txt.

Please let us know if this document …
IESG,

This document was submitted to the RFC Editor to be published as an
Informational Independent Submission:
draft-leung-mip4-proxy-mode-09.txt.

Please let us know if this document conflicts with the IETF standards
process or other work being done in the IETF community.

Four week timeout expires on 26 September 2008.


WiMAX Forum/3GPP2 Proxy Mobile IPv4

Mobile IPv4 is a standard mobility protocol that enables IPv4
device to move among networks while maintaining its IP address.
The mobile device has the Mobile IPv4 client function to signal its
location to the routing anchor, known as the Home Agent. However,
there are many IPv4 devices without such capability due to various
reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a
scheme based on having the Mobile IPv4 client function in a network
entity to provide mobility support for an unaltered and
mobility-unaware IPv4 device. This document also describes a
particular application of PMIPv4 as specified in the WiMAX Forum
and another application that is to be adopted in 3GPP2.


This independent submision was reviewed by George Tsirtsis.


Sincerely,

Sandy Ginoza - USC/ISI
Request for Comments Documents
2008-08-04
09 (System) New version available: draft-leung-mip4-proxy-mode-09.txt
2008-04-01
08 (System) New version available: draft-leung-mip4-proxy-mode-08.txt
2008-02-14
07 (System) New version available: draft-leung-mip4-proxy-mode-07.txt
2007-12-21
06 (System) New version available: draft-leung-mip4-proxy-mode-06.txt
2007-12-18
05 (System) New version available: draft-leung-mip4-proxy-mode-05.txt
2007-10-12
04 (System) New version available: draft-leung-mip4-proxy-mode-04.txt
2007-07-05
03 (System) New version available: draft-leung-mip4-proxy-mode-03.txt
2007-04-23
10 Jari Arkko
Authors, MIP4 chairs, ADs, Wimax liaison, and the IESG talked about this when it came clear that the authors want to publish this as an …
Authors, MIP4 chairs, ADs, Wimax liaison, and the IESG talked about this when it came clear that the authors want to publish this as an RFC. Given ongoing standardization work in NETLMM, lack of time, lack of IETF change control of a deployed protocol, it has been suggested that the authors take this to the RFC Editor as a vendor-specific protocol.
2007-04-23
10 Jari Arkko Draft Added by Jari Arkko in state AD is watching
2007-04-23
10 Jari Arkko [Note]: 'Suggested the author talks to RFC-Editor about this' added by Jari Arkko
2007-01-11
02 (System) New version available: draft-leung-mip4-proxy-mode-02.txt
2007-01-11
(System) Posted related IPR disclosure: Cisco's Statement about IPR Claimed in draft-leung-mip4-proxy-mode-00.txt
2006-06-29
01 (System) New version available: draft-leung-mip4-proxy-mode-01.txt
2006-02-28
00 (System) New version available: draft-leung-mip4-proxy-mode-00.txt