Subject: [netlmm] AD review of draft-ietf-netlmm-proxymip6, batch 3

From: Jari Arkko <[email-masked]>
Date: Sat, 05 Jan 2008 23:46:41 +0100

The next batch of comments is here. I am currently going through
Section 7, and I need to send at least one more batch before
the full review is complete.

Technical:

>    o  The mobile node's IPv6 home network prefix (MN-HNP)

Throughout the document, there is an assumption that only one
prefix will be provided. In general, the IPv6 model is to allow
multiple prefixes. Has the choice of exactly one prefix been
deliberate, and what would be the implications with respect
to data structures and signalling if this were not so?

Note that I'm not necessarily asking you to make the extension
to handle multiple prefixes. It may well be that the cost is too
great or that its an easily separable future enhancement. I just
asking for justification for this design choice.

> o  The mobile access gateway MUST be able identify the mobile node by
>    its MN-Identifier and it MUST be able to associate this identity
>    to the sender of any IPv4 or IPv6 packets on the access link.

This is not exact enough. Identify for what purpose? The rest of
the document goes into a lot more detail about how BCEs are
identified in a PBU, for instance. And you are not really associating
identifiers with IP packets, you associate them with the point-to-point
interface towards the mobile node.

Is there a reason for this statement or could you just rely on
what the rest of the document says?

> The prefix lifetime can also be an optional
> configuration parameter in the mobile node's policy profile.

This is inconsistent with Section 6.2 which does not mention
such an optional parameter.

> However, if
> the mobile node is DNAv6 enabled, as specified in [ID-DNAV6], it may
> not detect the link change due to DNAv6 optimizations and may not
> trigger the duplicate address detection (DAD) procedure for
> establishing the link-local address uniqueness on that new link.

The referred DNA specification is no longer the main delivery item
from the DNA WG; they have changed direction and will document
a "simple" DNA solution instead as this is what a few important
implementors have already done. Do you know if the same problem
appears there as well? If not, it may not be necessary to worry
about the DNA complications.

>    Further, if the mobile node uses an interface identifier that is not
>    based on EUI-64 identifier, such as specified in IPv6 Stateless
>    Autoconfiguration specification [RFC-4862], there is a very low
>    possibility of a link-local address collision between the two
>    neighbors on that access link.

This seems backwards. While there have been some reports of EUI-64
collisions, I would expect the likelihood of collisions to increase
mainly for manually configured IIDs. In any case, do you need to
talk about these probabilities? It does not seem to be an argument
that is used in the subsequent part of Section 6.8.

> 6.9.3. Retransmissions and Rate Limiting

Which rules from this Section actually change from RFC 3775? It is not
useful to restate or reformulate the same rules, but it would be useful
to document new requirements (e.g., due to timestamp usage). If most
of this section restates the old rules, please convert to the following
form instead "Retransmission and Rate Limiting rules for PBUs are as
specified for any BU in RFC 3775. However, ..."

Editorial:

>    o  It is responsible for detecting the mobile node's movements on the
>       access link and for initiating the mobility signaling with the
>       mobile node's local mobility anchor.

I have the same comment here as I had in batch 1 about the definition
of the MAG. Its really more about movements to and from the link than
mobility on the link itself; that would be handled by lower layers.

>    The following are the optional fields of the policy profile:
> 
>    o  The mobile node's IPv6 home network prefix (MN-HNP)
> 
>    o  Supported address configuration procedures (Stateful, Stateless or
>       both) on the access links in the Proxy Mobile IPv6 domain

The wording of the second field makes me believe that there's just
one setting per the whole domain and all mobiles. Is this so? If
yes, why is this a part of the profile for a mobile node? And if
not, perhaps you should clarify the language. Presumably different
mobile nodes could be offered different configuration procedures,
as long as the link's procedures remained constant for each individual
mobile node.

>  When stateless address autoconfiguration is supported on the link,
>  the mobile node can generate one or more IPv6 addresses by combining
>  the network prefix advertised on the access link with an interface
>  identifier, using the techniques described in Stateless
>  Autoconfiguration specification [RFC-4862] or as per Privacy
>  extension specification [RFC-4941].

Or RFC 3971. I would prefer to write the above in a slightly
different way to emphasize that you are not changing any
of the standard techniques:

   When stateless address autoconfiguration is supported on the link,
   the mobile node can generate one or more IPv6 addresses by
   standard IPv6 mechanisms such as Stateless Autoconfiguration
   specification [RFC-4862] and Privacy extension specification
   [RFC-4941].

>  When stateful address autoconfiguration is supported on the link, the
>  mobile node can obtain the address configuration from the DHCPv6
>  server using DHCPv6 client protocol, as specified in DHCPv6
>  specification [RFC-3315].

Same as above.

>  Additionally, other address configuration mechanisms specific to the
>  access link between the mobile node and the mobile access gateway may
>  also be used for pushing the address configuration to the mobile
>  node.

Perhaps add "This specification does not change the behavior of
address configuration mechanisms in any way."

> o  The identifier of the mobile node that the mobile access gateway
>    obtains typically as part of the access authentication or from the
>    notified network attachment event, can be a temporary identifier
>    and this identifier may also change at each re-authentication.
>    However, the mobile access gateway MUST be able to use this
>    identifier and obtain the mobile node's MN-Identifier from the
>    policy store, such as from the RADIUS attribute, Chargeable-User-
>    Identifier [RFC-4372].

I found the second sentence hard to parse. Maybe "... MUST be able to
obtain a stable MN-Identifier from a policy store instead. For
instance, in AAA-based systems the RADIUS attribute
Chargeable-User-Identifier [RFC-4372] may be used."

> 6.10.3. Routing State

I did not find that the text or the tables in this Section added anything
to what was already quite well explained in Section 6.10.4 and onwards.

Jari

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: Sri Gundavelli <[email-masked]>
Date: Sat, 5 Jan 2008 17:54:28 -0800 (PST)

Hi Jari,

Again, thanks for the detailed review. Please see inline.

Thanks
Sri

> asking for justification for this design choice.

This is intentional, all though nothing really stops from some one
assigning multiple HNP's to the same interface. Reasons:

- Just to keep the base document simple. Specification complexity, the
   plurality of HNP option presence related text in the PBU/PBA etc.
- Not a strong use case. We allocate a whole prefix to the mobile node
   and certainly MN's can configure more than one address, if not from
   different prefixes. Networks can always push address specific policies
   on a set of addresses as supposed to on prefix basis.
- Its fairly straight forward to extend this to allocate multiple HNP's.

> what the rest of the document says?

The MAG should have the ability to associate a RS message that it 
receives to the MN-Id for it to trigger the PMIP process. It also
needs to have some binding between the MN-Id for which it created the
mobility state and to the sender of the IP packets on the MN-AR
link, for security reasons. If the above text goes beyond than
what is required here, we can restate that the MAG should be able
to associate the P2P link to a given MN-Id, if that simplifies it.

> such an optional parameter.

Ok. We should add the prefix lifetime to the profile.

> about the DNA complications.

Totally agree.

Yes. We realized about the focus change in DNA WG recently. I dont
think we need to assume DNAv6 and solve this link-local address
collision issue. Since, the MN-AR link is a dynamically created P2P
link, the feedback is that deployments can handle this link-local
address collision issue as there will be CT between the MAG's and
the P2P link is moved between the MAG's. I suggest we:

- Remove the optional link-local address option field from the PBU
- Remove the processing rules specific to this link-local address
   caching in BCE and returning it in PBA
- Remove the DNAv6 specific references from 6.8

This simplies processing rules. Also, if CT mechanisms are not in
place and if the collision is an issue, we can probably state that
the MAG can always upload the link-local address of the MN to a
policy store and that should solve the issue.

> that is used in the subsequent part of Section 6.8.

I agree. We just state that there is a possibility of collision. If there
are context transfer schemes between the MAG's, the link is logically
moved to the new MAG and the issues does not exist. Same comment from
Alper on this DNAv6 assumption.

> specified for any BU in RFC 3775. However, ..."

Rule-1 defining the use INITIAL_BINDINGACK_TIMEOUT, and Rule-3 on the 
exponential backoff are straight from 3775. The other 2 rules (Part of
Rule 4) are PMIP6 specific. They are specified here, as they are being 
redefined for MAG usage, as supposed to MN usage. We can remove those
and just state as what you wrote above. One comment would be, it gives
some completeness to the section. But, we can remove it.

> mobility on the link itself; that would be handled by lower layers.

Ok.

> as long as the link's procedures remained constant for each individual

This can be enforced on a per-mobile basis. Will rephrase this as:

- Supported address configuration procedures (Stateful, Stateless or
both) for the mobile node in the Proxy Mobile IPv6 domain.

>   specification [RFC-4862] and Privacy extension specification

Ok

>>  specification [RFC-3315].

Ok. Will rephease this to emphasise on the use of the standard mechanisms.

> address configuration mechanisms in any way."

Sure

> Chargeable-User-Identifier [RFC-4372] may be used."

Ok. Will rephrase this as above.

> to what was already quite well explained in Section 6.10.4 and onwards.

The tables provide the hints on the routing state. Might be useful, but if
you think strongly, we can take this out.

Thanks
Sri

---

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Jan 2008 16:31:45 +0200

Sri,

> - Its fairly straight forward to extend this to allocate multiple HNP's.

Ok, fine.

> to associate the P2P link to a given MN-Id, if that simplifies it.

That would simplify it. That is I believe also the correct way to
implement it.

> Ok. We should add the prefix lifetime to the profile.

Good.

> policy store and that should solve the issue.

Mumble. Do you know if the new DNA solution has a similar issue? Suresh?

I am not sure we should rely on CT.

> some completeness to the section. But, we can remove it.

You can have a complete section if you want to (too), but you must specify
what the change is with respect to RFC 3775.

Ok.

> you think strongly, we can take this out.

At least move them to an appendix, or take out entirely.

Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 14 Jan 2008 13:41:32 -0800

> Ok. We should add the prefix lifetime to the profile.

?? Storing the prefix in the policy profile is optional. How
can the prefix lifetime be mandatory?

> policy store and that should solve the issue.

I suggest we keep the text about carrying the MN's link local
in the Proxy BU and Proxy BAck and storing this in the policy
profile. I don't think we should assume context transfer
mechanism between the MAGs. I am fine with removing references
to DNAv6.

Vijay

---

From: Jari Arkko <[email-masked]>
Date: Mon, 14 Jan 2008 23:52:26 +0200

Vijay,

> can the prefix lifetime be mandatory?

Did someone mention anything about mandatory? But I think the
document needs to be consistent about what capabilities
the policy profile may have.

> mechanism between the MAGs. I am fine with removing references
That may be the right approach.  But I would still like to know whether
the new DNAv6 solution changes the situation from what it was. If not,
we should definitely keep the support. But again, pointing to the old
DNAv6 solution may not be worthwhile.

Jari

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 14 Jan 2008 22:46:30 -0500

Hi Jari,

> Mumble. Do you know if the new DNA solution has a similar issue? Suresh?

Yes. The new DNA solution as of today has the exact same issue. We do 
two different tests for detecting link change (NS/NA based and RS/RA 
based). The NS/NA test will conclude that there is a link change since 
the hardware address of the new MAG is different from the old one's but 
the RS/RA test will conclude that there is no link change. The way the 
draft is written the host will conclude (SHOULD) that there is no link 
change. There is an ongoing dicussion on the DNA ml regarding the 
precedence of these two tests and we might end up updating the draft to 
change the precedences. This issue might be resolved by the change (if 
any).

Thanks
Suresh

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 15 Jan 2008 00:31:22 -0800

Hi Jari,

Please see inline.

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Monday, January 14, 2008 6:32 AM
> To: Sri Gundavelli
> Cc: [email-masked]; 
> [email-masked]; Suresh Krishnan (QB/EMC)
> Subject: Re: [netlmm] AD review of 
> draft-ietf-netlmm-proxymip6, batch 3
> 
> Sri,
> 

I agree. Will change it.

> I am not sure we should rely on CT.

Given that the DNA spec is still in definition phase and under active
discussions, may be its practical we leave that out and still keep the
spec complete by giving the MAG the option of uploading the link-local
address to a policy store or sending it to the new MAG over CT. If
the solution that comes out from DNA group later requires this support,
we can have a one page document on that part. I'd not say this, if
the DNA spec is completly done. Also, clearly this is not issue in most
cases, as explained in the doc. Any case, if DNA camp disagrees, fine
to keep this one more option.

> what the change is with respect to RFC 3775.

Ok. Will do this.

Ok.

---

From: Jari Arkko <[email-masked]>
Date: Fri, 25 Jan 2008 16:57:04 +0200

Suresh,

> the hardware address of the new MAG is different from the old one's
> but the RS/RA test will conclude that there is no link change. The way
> the draft is written the host will conclude (SHOULD) that there is no
> link change. There is an ongoing dicussion on the DNA ml regarding the
> precedence of these two tests and we might end up updating the draft
> to change the precedences. This issue might be resolved by the change
> (if any).

Thanks for the information. Given the above, I would recommend keeping
the current DNA text in the draft.

Jari