WiMAX Forum / 3GPP2 Proxy Mobile IPv4
draft-leung-mip4-proxy-mode-10

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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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.

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

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.