Subject: [netlmm] Dave Thaler's review discussions

From: "Narayanan, Vidya" <[email-masked]>
Date: Sun, 13 Apr 2008 23:30:33 -0700

Attached. 

Subject: RE: dave thaler's review of draft-ietf-netlmm-proxymip6
From: "Sri Gundavelli" <[email-masked]>
To: "Sri Gundavelli" <[email-masked]>, "Jari Arkko" <[email-masked]>
Cc: "Netlmm Chairs" <[email-masked]>, <[email-masked]>, "IESG" <[email-masked]>, "Dave Thaler" <[email-masked]>
Date: Sun, 13 Apr 2008 23:28:26 -0700

FYI. Response to Dave Thalar's review.

All issues resolved, except the specific details on
how the link-local address of the MAG is stored in
the BCE as supposed to the MN's link-local address.
This will essentially ensure the protocol does not
break if the MN configures multiple link-local addresses.
Also, there is the question on if we need a seperate
registry for ATT, or if we can leverage on IF Type
registry, this is more an admintrative issue.

Sri

> -----Original Message-----
> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Tuesday, April 01, 2008 12:58 AM
> To: Jari Arkko
> Cc: Netlmm Chairs; 
> [email-masked]; IESG; Dave Thaler
> Subject: dave thaler's review of draft-ietf-netlmm-proxymip6
> 
> Hi Dave,
> 
> Thanks for your review.
> 
> Please see inline.
> 
> Regards
> Sri
> 
> 
> 
> On Tue, 1 Apr 2008, Jari Arkko wrote:
> 
> > Here's Dave Thaler's review from yesterday. I have not had 
> much time to
> > review the suggestions in detail, but my starting point is to say
> > "please fix all of these". There is also some overlap with 
> other reviews
> > that we've received, e.g., interface identifier issue was already
> > brought up by Phil Roberts.
> >
> > Thank you Dave for the review!
> >
> >> At Jari's request, I have reviewed 
> draft-ietf-netlmm-proxymip6-11, and found
> >> a number of technical issues which I will summarize below, 
> and a large number
> >> of editorial nits.  A PDF with full comments in context, 
> and the editorial
> >> nits, is at
> >> 
> http://research.microsoft.com/users/dthaler/draft-ietf-netlmm-
> proxymip6-11-dthaler.pdf
> >>
> 
> Will fix all the nits. Thanks.
> 
> 
> >> For anyone on the IP Directorate who hasn't read this, the 
> short summary is:
> >> don't change the hosts, don't use any route optimization 
> just a tunnel from
> >> the local router ("MAG") to the home agent ("LMA"), and 
> make the on-link
> >> prefix follow the node as it moves between point-to-point 
> links so that the
> >> current router is the one with the tunnel to the home 
> agent and the node's
> >> prefix that the router can advertise to the node in an RA.
> >>
> >> Summary of technical issues (in no particular order)
> >> -------------------------------------------------
> >> 1) The definition of "interface identifier" is not well 
> defined, and is
> >>    in fact not the same as the term of the same name in 
> the IPv6 Addressing
> >>    Architecture (RFC-4291) or Stateless Address 
> Autoconfiguration (RFC-4862).
> >>    And it's arguable as to whether it's different from 
> what is defined in
> >>    RFC-5072, the IPv6-over-PPP RFC (which defines it on a 
> PPP link only,
> >>    whereas PMIP isn't PPP-specific).
> >>
> >>    Specifically, the PMIP document appears to assume that
> >>    a) the interface identifier is a property of a link 
> (not each IPv6 address
> >>       on the link, which might be a CGA or a Privacy 
> address, etc), and
> >>    b) the interface identifier is unique across different 
> interfaces of the
> >>       node, even if those interfaces connect to different 
> links, and
> >>    c) the interface identifier is unique across all nodes 
> in the domain
> >>       (not just across those on the same link)
> >>
> >>    It doesn't explicitly state the above, it just has 
> rules that rely on
> >>    those being true, and it has a goal of not changing the 
> end host, which
> >>    seems to really limit the applicability in terms of L2 
> protocols to just
> >>    PPP and similar protocols but not 802.3 or 802.11 which 
> are currently
> >>    listed as possible types.
> >>
> >>    Some places (e.g. p67) actually imply that the 
> "interface identifier"
> >>    is instead _defined_ to be the link layer address, 
> rather than that
> >>    being only a possibility that the values are equal.  So 
> there's much
> >>    confusion throughout regarding this term.
> >>
> 
> This is the terminology problem. The draft referred to L2 
> identifier of
> the MN's attached interface Ex: MAC address. It identifies 
> the physical
> or hardware address of the attached MN's interface. We will fix this.
> This identifier is no way related to the identifier part of the IPv6
> address. Point well taken, we will fix it.
> 
> 
> 
> >> 2) Related to issue 1, the document does not clearly list 
> the criteria
> >>    for what it expects from the link layer (i.e. what 
> criteria does a link
> >>    type have to meet before PMIP can work over it).  Some 
> criteria are
> >>    scattered around the document, and some are implied but 
> not stated,
> >>    as noted above.  Some criteria scattered around are, in 
> addition to
> >>    the interface identifier parts noted above:
> >>    a) has to be a point-to-point link
> >>    b) provide L2 indications of when the link comes up (not all p2p
> >>       interface types provide this... IP-in-IP configured 
> tunnels don't
> >>       for instance)
> >>    c) support authorization as part of bringing up the link
> >>
> >>    The document should clearly list what the criteria are in one
> >>    place.
> >>
> 
> Ok
> 
> 
> >> 3) Although the on-link prefix roams with the host, the link-local
> >>    address of the router doesn't.  This impacts simple DNAv6 (and
> >>    DNAv4 if you support IPv4 in the future) since a simple DNAv6-
> >>    capable host will do ND for the router's link-local address, not
> >>    find it, and conclude it's on a different link (e.g., tear down
> >>    its old privacy address and all TCP connections using it, and
> >>    generate a new privacy address).  I don't think this is a good
> >>    thing.  What I had expected to see is that the router (MAG)
> >>    learns its link-local address and link-layer address from the
> >>    home agent (LMA) just like it learns the home network prefix,
> >>    so that the node sees the same link and keeps its TCP 
> connections
> >>    up.  But PMIP doesn't do this, nor does it even discuss this
> >>    issue.  (It's also worth pointing out to the authors of PMIP
> >>    that the DNA WG is moving forward with the Simple DNAv6 protocol
> >>    and not the original DNAv6 protocol, per discussion at the last
> >>    IETF meeting.)
> >>
> 
> This specific approach was suggested last week by Julien Laganier.
> We are currently storing the MN's link-local address in its binding
> cache and at each handoff the serving MAG is ensuring its not using
> the address the MN was using. The alternative to this approach is
> to store the MAG's address in the binding cache and the serving
> MAG can learn this address and configure it. I thought the later
> approach all thought is a very clean approach, however may have
> implications when using SEND, as all the MAG's should be able to
> assert their ownership on that address.
> 
> 
> 
> >> 4) As currently specified, the recommended mode of PMIP is
> >>    incompatible with SEND, and even spoofs IP addresses as part
> >>    of the protocol (section 6.9.3).  All this would be unnecessary
> >>    in the alternative approach described in issue 3 above.  It
> >>    seems extremely questionable to me to recommend (or even
> >>    suggest) approaches which don't work with SEND and which
> >>    promote spoofing of addresses.  While we're on security issues,
> >>    some statements about addresses and interface identifiers
> >>    are worded in a way that they assume CGA's don't exist either,
> >>    which is basically the same as issue 1 above and could be
> >>    fixed with only editorial changes.
> >>
> 
> This is related to issue#3 above. The change in approach for that
> one will fix this issue as well. The spec listed few approaches
> and one of them is essentially a new MAG timing out the prev DR
> entry. This is not mandated, however. But, I see the concern and
> will address this.
> 
> 
> 
> >> 5) I still can't figure out why the home agent (LMA) needs to know
> >>    the mobile node's link-local IPv6 address.  There's a bunch of
> >>    mechanism for passing it and storing it, but I can't figure out
> >>    why.  It might be related to issue #3 (i.e. might go away if
> >>    the router's own link-local address came with the home address
> >>    prefix).
> >>
> 
> This is related to issue #3. We are moving the MN's link-local
> address to its BCE, so the serving MAG can download it and ensure
> it does not endup configuring the same address on the p2p link,
> in case the MN does not trigger DAD procedure for the link-local
> address uniquess establishment on the new link after handoff.
> 
> 
> >> 6) When roaming away from a router (MAG), the doc says the router
> >>    sends an RA with a prefix lifetime of 0.  Unless I'm missing
> >>    something, this is either unnecessary (since the node won't
> >>    get it if the node is already gone from the link) or harmful
> >>    since the node will expire its IP address and take down its
> >>    TCP sessions.  I can't figure out any case where it's actually
> >>    helpful for anything.
> >>
> 
> The MAG should have the ability to withdraw a prefix that it assigned
> to a mobile. Just as how an access router in fixed networks can
> expire a prefix. The draft does recommend tearing down the layer-2
> such as shutting down the p2p link and that should provide the same
> capability. It is understood that withdrawing the prefix on the link
> will result in mobile loosing the configured address on the attached
> interface.
> 
> 
> >> 7) The model when EnableMAGLocalRouting is configured to be false
> >>    and a MN and a CN are attached to different links of the same
> >>    router seems awfully weird to me.  Basically the router has to
> >>    forward the packets over the tunnel to the home agent, which
> >>    then just forwards them right back over the same point-to-point
> >>    tunnel.  I don't think this happens in any other point-to-point
> >>    case today (I think such packets more likely get dropped),
> >>    and I'm concerned there may be problems with this approach,
> >>    although I can't say for sure, except to say that it was pretty
> >>    hard to figure out this is what it's doing and it should at
> >>    least call it out in a picture or something to make it clear
> >>    that this is just weird.
> >>
> 
> Accounting and Policy control is one reason why operators like to
> do this. LMA/HA is the policy enforcement point. We do this today
> in Mobile IPv4 as well. For various reasons, the home operator likes
> to see the mobile traffic flow through the home anchor point, its
> simply for administrative reasons.
> 
> 
> 
> 
> >> 8) The protocol creates a delay between the host sends an RS and
> >>    when it gets an RA, which could be large (since there could
> >>    be packet loss in the exchange that happens between the MAG
> >>    and the LMA before the MAG can send the RA).  This is at odds
> >>    with other IETF efforts to decrease such delay, e.g. for cases
> >>    when one is roaming from one domain to another and using MIPv6,
> >>    or for the case when one temporarily loses connectivity and
> >>    wants to regain it asap.  The fact that it can adversely affect
> >>    these cases isn't called out, just the fact that there may be
> >>    a delay (and one has to look in section 7.1 to find it, it's
> >>    not mentioned in the overview, which incorrectly shows the
> >>    node delaying sending the RS until long after the link is up).
> >>
> 
> The event that the MAG uses for triggering PMIP signaling on behalf
> of a mobile node is typically after receving an ACCESS_AUTH event.
> The event could be a signal from the radio network, or an event
> after successful L2 authentication. We were bit loose on this
> and were showing the RS as the event that triggers PMIP signaling.
> We will fix this.
> 
> 
> 
> >> 9) The protocol invents another link type numbering space that
> >>    IANA has to manage.  It's not clear why the existing ifType
> >>    that IANA already manages won't do the job.
> >>
> 
> Ok. We just need a registry that has all the access technology
> types. We will review this.
> 
> 
> >> 10) The protocol assumes that the router (MAG) has no addresses
> >>    in the on-link prefix, but that it does have a global address
> >>    on the same interface.  The first statement violates RFC-4291
> >>    section 4.9.1, which requires that the router have the
> >>    subnet router anycast address in each on-link prefix.
> >>    The second statement seems unnecessary, why can't it just
> >>    use the global address of some other interface for sending
> >>    messages to the home agent (LMA)?
> >>
> 
> The address that the MAG uses as the source address in PMIP
> signaling is the global address configured on the egress
> interface of the MAG. It is not the address on the P2P link
> between the MAG and the MN. This address is referred to as
> the Proxy-CoA and this is mentioned in the terminology section
> and also identified in the illustrations. We will clarify this
> to ensure this is clear.
> 
> 
> Dave, thanks for your time on this review. !
> 
> Regards
> Sri
> 
> 
> >> -Dave Thaler
> >
> >

Subject: RE: dave thaler's review of draft-ietf-netlmm-proxymip6
From: "Dave Thaler" <[email-masked]>
To: "Jari Arkko" <[email-masked]>, "Sri Gundavelli" <[email-masked]>
Cc: "Netlmm Chairs" <[email-masked]>, <[email-masked]>, "IESG" <[email-masked]>
Date: Thu, 10 Apr 2008 11:19:44 -0700

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Thursday, April 10, 2008 12:50 AM
> To: Sri Gundavelli
> Cc: Netlmm Chairs; [email-masked]; IESG;
> Dave Thaler
> Subject: Re: dave thaler's review of draft-ietf-netlmm-proxymip6
>
> Thanks for your suggestions on how to fix these things, Dave (in
> particular the link local issue). And thanks for your responses, Sri.
>
> I am commenting on few remaining pieces below:
>
> >>> 3) Although the on-link prefix roams with the host, the link-local
> >>> address of the router doesn't. This impacts simple DNAv6 (and
> >>> DNAv4 if you support IPv4 in the future) since a simple DNAv6-
> >>> capable host will do ND for the router's link-local address, not
> >>> find it, and conclude it's on a different link (e.g., tear down
> >>> its old privacy address and all TCP connections using it, and
> >>> generate a new privacy address). I don't think this is a good
> >>> thing. What I had expected to see is that the router (MAG)
> >>> learns its link-local address and link-layer address from the
> >>> home agent (LMA) just like it learns the home network prefix,
> >>> so that the node sees the same link and keeps its TCP connections
> >>> up. But PMIP doesn't do this, nor does it even discuss this
> >>> issue. (It's also worth pointing out to the authors of PMIP
> >>> that the DNA WG is moving forward with the Simple DNAv6 protocol
> >>> and not the original DNAv6 protocol, per discussion at the last
> >>> IETF meeting.)
> >>>
> >
> > This specific approach was suggested last week by Julien Laganier.
> > We are currently storing the MN's link-local address in its binding
> > cache and at each handoff the serving MAG is ensuring its not using
> > the address the MN was using. The alternative to this approach is
> > to store the MAG's address in the binding cache and the serving
> > MAG can learn this address and configure it. I thought the later
> > approach all thought is a very clean approach, however may have
> > implications when using SEND, as all the MAG's should be able to
> > assert their ownership on that address.
>
> I think I would like to see Dave's approach in the document. Note that
> we've separately talked about the MAC addresses being necessary, too,
> if
> someone runs NETLMM on a link that requires address resolution (PPP and
> 3GPP for instance do not).

Yes keeping the same MAC address is necessary for DNA as well.

> With regards to the SEND issue, it is true that Dave's approach causes
> some issues. Basically, the question is if the MAG needs to pretend to
> have the same SEND identity as the previous MAG. If yes, then the
> solution is either private key sharing (bad) or some sort of delegation
> certificate solution. I'll note that the latter is needed for proxy ND
> anyway and is in the works in the CSI WG.
>
> On the other hand, I'm not convinced that the MAG needs to claim the
> same crypto identity. RFC 3971 says that the reception of an RS with
> unrecognized identity will cause the certificate path learning process
> to be triggered. So every MAG can have a different key pair. The
> problem
> with this is that since a certificate would also list the MAG's own IP
> address, this either implies configuring each MAG with N certs for each
> N prefix available from the LMA, or some dynamic certificate assignment
> on a per need basis.
>
> Thoughts?

The goal of PMIP is to work without changes to the host.
Existing hosts don't have SEND implementations so any solution that
preserves the MAC and link-local address of the router will meet
that goal.  We do want hosts to have SEND implementations in the
future of course, so I agree that working with the CSI WG (which is
chartered to remove some of the issues blocking current implementations)
can provide a solution which will support this in some way with SEND.

If the MAG does not claim the same crypto identity, I wonder if
DNA-capable hosts might want to think that you've moved links.
If they do, you haven't solved anything.  So it'd be important to
get consensus on this point first (including in the DNA WG I would
think).

Certainly it'd be safest (i.e. no need to ask the above question) if
the MAG did claim the same crypto identity, although I don't really
know if that's practical.

> >>> 6) When roaming away from a router (MAG), the doc says the router
> >>> sends an RA with a prefix lifetime of 0. Unless I'm missing
> >>> something, this is either unnecessary (since the node won't
> >>> get it if the node is already gone from the link) or harmful
> >>> since the node will expire its IP address and take down its
> >>> TCP sessions. I can't figure out any case where it's actually
> >>> helpful for anything.
> >>>
> >
> > The MAG should have the ability to withdraw a prefix that it assigned
> > to a mobile. Just as how an access router in fixed networks can
> > expire a prefix. The draft does recommend tearing down the layer-2
> > such as shutting down the p2p link and that should provide the same
> > capability. It is understood that withdrawing the prefix on the link
> > will result in mobile loosing the configured address on the attached
> > interface.
>
> Lets go for the shutting down of the link.
>
> >>> 7) The model when EnableMAGLocalRouting is configured to be false
> >>> and a MN and a CN are attached to different links of the same
> >>> router seems awfully weird to me. Basically the router has to
> >>> forward the packets over the tunnel to the home agent, which
> >>> then just forwards them right back over the same point-to-point
> >>> tunnel. I don't think this happens in any other point-to-point
> >>> case today (I think such packets more likely get dropped),
> >>> and I'm concerned there may be problems with this approach,
> >>> although I can't say for sure, except to say that it was pretty
> >>> hard to figure out this is what it's doing and it should at
> >>> least call it out in a picture or something to make it clear
> >>> that this is just weird.
> >>>
> >
> > Accounting and Policy control is one reason why operators like to
> > do this. LMA/HA is the policy enforcement point. We do this today
> > in Mobile IPv4 as well. For various reasons, the home operator likes
> > to see the mobile traffic flow through the home anchor point, its
> > simply for administrative reasons.
>
> Dave, having access node forward traffic to a central node without
> doing
> a local routing decision is fairly standard practice for the reasons
> that Sri mentioned. One way to look at this is to think of a MAG
> serving
> a particular MN as one slice in a virtual router. It only knows the MN
> and LMA interfaces. The LMA will make the real routing decision and
> forward the packet back to the another MN's tunnel and another virtual
> slice in the same physical box. Not the optimal way to do things, but
> very common.

I'm not arguing with that.  My point was that if you don't know that
it's "fairly standard practice", it's not at all obvious in the doc.
That's why I asked for a picture or some other way of making it clear
to the reader what's going on.

> >>> 9) The protocol invents another link type numbering space that
> >>> IANA has to manage. It's not clear why the existing ifType
> >>> that IANA already manages won't do the job.
> >>>
> >
> > Ok. We just need a registry that has all the access technology
> > types. We will review this.
>
> There are some expectations that NETLMM has on how types are used. They
> are used for exactly one reason, in the multiple-interfaces attachment
> case to prevent NETLMM from accidentally de-registering your other
> interface when you attach with a new one. You have to be a bit careful
> with the access type definitions to get this right. For instance, if
> the
> access types include 802.11b and 802.11g separately, this would be bad
> as my interface card can do both using the same MAC address.
>
> But it seems ifType numbers include 80211 as one item, so maybe this is
> not a problem. I have not thought about the other interfaces. The point
> is that the list in the current document has been verified for this,
> whereas the ifType list has not.

Understood.  In my opinion though, that's not sufficient justification
to rule out ifType, which would remove a process step.

-Dave
> Jari

Subject: Re: dave thaler's review of draft-ietf-netlmm-proxymip6
From: "Jari Arkko" <[email-masked]>
To: "Sri Gundavelli" <[email-masked]>
Cc: "Netlmm Chairs" <[email-masked]>, <[email-masked]>, "IESG" <[email-masked]>, "Dave Thaler" <[email-masked]>
Date: Thu, 10 Apr 2008 00:50:06 -0700

Thanks for your suggestions on how to fix these things, Dave (in
particular the link local issue). And thanks for your responses, Sri.

I am commenting on few remaining pieces below:

>
>>> 3) Although the on-link prefix roams with the host, the link-local
>>> address of the router doesn't. This impacts simple DNAv6 (and
>>> DNAv4 if you support IPv4 in the future) since a simple DNAv6-
>>> capable host will do ND for the router's link-local address, not
>>> find it, and conclude it's on a different link (e.g., tear down
>>> its old privacy address and all TCP connections using it, and
>>> generate a new privacy address). I don't think this is a good
>>> thing. What I had expected to see is that the router (MAG)
>>> learns its link-local address and link-layer address from the
>>> home agent (LMA) just like it learns the home network prefix,
>>> so that the node sees the same link and keeps its TCP connections
>>> up. But PMIP doesn't do this, nor does it even discuss this
>>> issue. (It's also worth pointing out to the authors of PMIP
>>> that the DNA WG is moving forward with the Simple DNAv6 protocol
>>> and not the original DNAv6 protocol, per discussion at the last
>>> IETF meeting.)
>>>
>
> This specific approach was suggested last week by Julien Laganier.
> We are currently storing the MN's link-local address in its binding
> cache and at each handoff the serving MAG is ensuring its not using
> the address the MN was using. The alternative to this approach is
> to store the MAG's address in the binding cache and the serving
> MAG can learn this address and configure it. I thought the later
> approach all thought is a very clean approach, however may have
> implications when using SEND, as all the MAG's should be able to
> assert their ownership on that address.

I think I would like to see Dave's approach in the document. Note that
we've separately talked about the MAC addresses being necessary, too, if
someone runs NETLMM on a link that requires address resolution (PPP and
3GPP for instance do not).

With regards to the SEND issue, it is true that Dave's approach causes
some issues. Basically, the question is if the MAG needs to pretend to
have the same SEND identity as the previous MAG. If yes, then the
solution is either private key sharing (bad) or some sort of delegation
certificate solution. I'll note that the latter is needed for proxy ND
anyway and is in the works in the CSI WG.

On the other hand, I'm not convinced that the MAG needs to claim the
same crypto identity. RFC 3971 says that the reception of an RS with
unrecognized identity will cause the certificate path learning process
to be triggered. So every MAG can have a different key pair. The problem
with this is that since a certificate would also list the MAG's own IP
address, this either implies configuring each MAG with N certs for each
N prefix available from the LMA, or some dynamic certificate assignment
on a per need basis.

Thoughts?

>>> 6) When roaming away from a router (MAG), the doc says the router
>>> sends an RA with a prefix lifetime of 0. Unless I'm missing
>>> something, this is either unnecessary (since the node won't
>>> get it if the node is already gone from the link) or harmful
>>> since the node will expire its IP address and take down its
>>> TCP sessions. I can't figure out any case where it's actually
>>> helpful for anything.
>>>
>
> The MAG should have the ability to withdraw a prefix that it assigned
> to a mobile. Just as how an access router in fixed networks can
> expire a prefix. The draft does recommend tearing down the layer-2
> such as shutting down the p2p link and that should provide the same
> capability. It is understood that withdrawing the prefix on the link
> will result in mobile loosing the configured address on the attached
> interface.

Lets go for the shutting down of the link.

>>> 7) The model when EnableMAGLocalRouting is configured to be false
>>> and a MN and a CN are attached to different links of the same
>>> router seems awfully weird to me. Basically the router has to
>>> forward the packets over the tunnel to the home agent, which
>>> then just forwards them right back over the same point-to-point
>>> tunnel. I don't think this happens in any other point-to-point
>>> case today (I think such packets more likely get dropped),
>>> and I'm concerned there may be problems with this approach,
>>> although I can't say for sure, except to say that it was pretty
>>> hard to figure out this is what it's doing and it should at
>>> least call it out in a picture or something to make it clear
>>> that this is just weird.
>>>
>
> Accounting and Policy control is one reason why operators like to
> do this. LMA/HA is the policy enforcement point. We do this today
> in Mobile IPv4 as well. For various reasons, the home operator likes
> to see the mobile traffic flow through the home anchor point, its
> simply for administrative reasons.

Dave, having access node forward traffic to a central node without doing
a local routing decision is fairly standard practice for the reasons
that Sri mentioned. One way to look at this is to think of a MAG serving
a particular MN as one slice in a virtual router. It only knows the MN
and LMA interfaces. The LMA will make the real routing decision and
forward the packet back to the another MN's tunnel and another virtual
slice in the same physical box. Not the optimal way to do things, but
very common.

>
>>> 9) The protocol invents another link type numbering space that
>>> IANA has to manage. It's not clear why the existing ifType
>>> that IANA already manages won't do the job.
>>>
>
> Ok. We just need a registry that has all the access technology
> types. We will review this.

There are some expectations that NETLMM has on how types are used. They
are used for exactly one reason, in the multiple-interfaces attachment
case to prevent NETLMM from accidentally de-registering your other
interface when you attach with a new one. You have to be a bit careful
with the access type definitions to get this right. For instance, if the
access types include 802.11b and 802.11g separately, this would be bad
as my interface card can do both using the same MAC address.

But it seems ifType numbers include 80211 as one item, so maybe this is
not a problem. I have not thought about the other interfaces. The point
is that the list in the current document has been verified for this,
whereas the ifType list has not.

Jari

Subject: dave thaler's review of draft-ietf-netlmm-proxymip6
From: "Sri Gundavelli" <[email-masked]>
To: "Jari Arkko" <[email-masked]>
Cc: "Netlmm Chairs" <[email-masked]>, <[email-masked]>, "IESG" <[email-masked]>, "Dave Thaler" <[email-masked]>
Date: Tue, 1 Apr 2008 00:57:41 -0700

Hi Dave,

Thanks for your review.

Please see inline.

Regards
Sri

On Tue, 1 Apr 2008, Jari Arkko wrote:

> Here's Dave Thaler's review from yesterday. I have not had much time to
> review the suggestions in detail, but my starting point is to say
> "please fix all of these". There is also some overlap with other reviews
> that we've received, e.g., interface identifier issue was already
> brought up by Phil Roberts.
>
> Thank you Dave for the review!
>
>> At Jari's request, I have reviewed draft-ietf-netlmm-proxymip6-11, and found
>> a number of technical issues which I will summarize below, and a large number
>> of editorial nits.  A PDF with full comments in context, and the editorial
>> nits, is at
>> http://research.microsoft.com/users/dthaler/draft-ietf-netlmm-proxymip6-11-dthaler.pdf
>>

Will fix all the nits. Thanks.

>> For anyone on the IP Directorate who hasn't read this, the short summary is:
>> don't change the hosts, don't use any route optimization just a tunnel from
>> the local router ("MAG") to the home agent ("LMA"), and make the on-link
>> prefix follow the node as it moves between point-to-point links so that the
>> current router is the one with the tunnel to the home agent and the node's
>> prefix that the router can advertise to the node in an RA.
>>
>> Summary of technical issues (in no particular order)
>> -------------------------------------------------
>> 1) The definition of "interface identifier" is not well defined, and is
>>    in fact not the same as the term of the same name in the IPv6 Addressing
>>    Architecture (RFC-4291) or Stateless Address Autoconfiguration (RFC-4862).
>>    And it's arguable as to whether it's different from what is defined in
>>    RFC-5072, the IPv6-over-PPP RFC (which defines it on a PPP link only,
>>    whereas PMIP isn't PPP-specific).
>>
>>    Specifically, the PMIP document appears to assume that
>>    a) the interface identifier is a property of a link (not each IPv6 address
>>       on the link, which might be a CGA or a Privacy address, etc), and
>>    b) the interface identifier is unique across different interfaces of the
>>       node, even if those interfaces connect to different links, and
>>    c) the interface identifier is unique across all nodes in the domain
>>       (not just across those on the same link)
>>
>>    It doesn't explicitly state the above, it just has rules that rely on
>>    those being true, and it has a goal of not changing the end host, which
>>    seems to really limit the applicability in terms of L2 protocols to just
>>    PPP and similar protocols but not 802.3 or 802.11 which are currently
>>    listed as possible types.
>>
>>    Some places (e.g. p67) actually imply that the "interface identifier"
>>    is instead _defined_ to be the link layer address, rather than that
>>    being only a possibility that the values are equal.  So there's much
>>    confusion throughout regarding this term.
>>

This is the terminology problem. The draft referred to L2 identifier of
the MN's attached interface Ex: MAC address. It identifies the physical
or hardware address of the attached MN's interface. We will fix this.
This identifier is no way related to the identifier part of the IPv6
address. Point well taken, we will fix it.

>> 2) Related to issue 1, the document does not clearly list the criteria
>>    for what it expects from the link layer (i.e. what criteria does a link
>>    type have to meet before PMIP can work over it).  Some criteria are
>>    scattered around the document, and some are implied but not stated,
>>    as noted above.  Some criteria scattered around are, in addition to
>>    the interface identifier parts noted above:
>>    a) has to be a point-to-point link
>>    b) provide L2 indications of when the link comes up (not all p2p
>>       interface types provide this... IP-in-IP configured tunnels don't
>>       for instance)
>>    c) support authorization as part of bringing up the link
>>
>>    The document should clearly list what the criteria are in one
>>    place.
>>

Ok

>> 3) Although the on-link prefix roams with the host, the link-local
>>    address of the router doesn't.  This impacts simple DNAv6 (and
>>    DNAv4 if you support IPv4 in the future) since a simple DNAv6-
>>    capable host will do ND for the router's link-local address, not
>>    find it, and conclude it's on a different link (e.g., tear down
>>    its old privacy address and all TCP connections using it, and
>>    generate a new privacy address).  I don't think this is a good
>>    thing.  What I had expected to see is that the router (MAG)
>>    learns its link-local address and link-layer address from the
>>    home agent (LMA) just like it learns the home network prefix,
>>    so that the node sees the same link and keeps its TCP connections
>>    up.  But PMIP doesn't do this, nor does it even discuss this
>>    issue.  (It's also worth pointing out to the authors of PMIP
>>    that the DNA WG is moving forward with the Simple DNAv6 protocol
>>    and not the original DNAv6 protocol, per discussion at the last
>>    IETF meeting.)
>>

This specific approach was suggested last week by Julien Laganier.
We are currently storing the MN's link-local address in its binding
cache and at each handoff the serving MAG is ensuring its not using
the address the MN was using. The alternative to this approach is
to store the MAG's address in the binding cache and the serving
MAG can learn this address and configure it. I thought the later
approach all thought is a very clean approach, however may have
implications when using SEND, as all the MAG's should be able to
assert their ownership on that address.

>> 4) As currently specified, the recommended mode of PMIP is
>>    incompatible with SEND, and even spoofs IP addresses as part
>>    of the protocol (section 6.9.3).  All this would be unnecessary
>>    in the alternative approach described in issue 3 above.  It
>>    seems extremely questionable to me to recommend (or even
>>    suggest) approaches which don't work with SEND and which
>>    promote spoofing of addresses.  While we're on security issues,
>>    some statements about addresses and interface identifiers
>>    are worded in a way that they assume CGA's don't exist either,
>>    which is basically the same as issue 1 above and could be
>>    fixed with only editorial changes.
>>

This is related to issue#3 above. The change in approach for that
one will fix this issue as well. The spec listed few approaches
and one of them is essentially a new MAG timing out the prev DR
entry. This is not mandated, however. But, I see the concern and
will address this.

>> 5) I still can't figure out why the home agent (LMA) needs to know
>>    the mobile node's link-local IPv6 address.  There's a bunch of
>>    mechanism for passing it and storing it, but I can't figure out
>>    why.  It might be related to issue #3 (i.e. might go away if
>>    the router's own link-local address came with the home address
>>    prefix).
>>

This is related to issue #3. We are moving the MN's link-local
address to its BCE, so the serving MAG can download it and ensure
it does not endup configuring the same address on the p2p link,
in case the MN does not trigger DAD procedure for the link-local
address uniquess establishment on the new link after handoff.

>> 6) When roaming away from a router (MAG), the doc says the router
>>    sends an RA with a prefix lifetime of 0.  Unless I'm missing
>>    something, this is either unnecessary (since the node won't
>>    get it if the node is already gone from the link) or harmful
>>    since the node will expire its IP address and take down its
>>    TCP sessions.  I can't figure out any case where it's actually
>>    helpful for anything.
>>

The MAG should have the ability to withdraw a prefix that it assigned
to a mobile. Just as how an access router in fixed networks can
expire a prefix. The draft does recommend tearing down the layer-2
such as shutting down the p2p link and that should provide the same
capability. It is understood that withdrawing the prefix on the link
will result in mobile loosing the configured address on the attached
interface.

>> 7) The model when EnableMAGLocalRouting is configured to be false
>>    and a MN and a CN are attached to different links of the same
>>    router seems awfully weird to me.  Basically the router has to
>>    forward the packets over the tunnel to the home agent, which
>>    then just forwards them right back over the same point-to-point
>>    tunnel.  I don't think this happens in any other point-to-point
>>    case today (I think such packets more likely get dropped),
>>    and I'm concerned there may be problems with this approach,
>>    although I can't say for sure, except to say that it was pretty
>>    hard to figure out this is what it's doing and it should at
>>    least call it out in a picture or something to make it clear
>>    that this is just weird.
>>

Accounting and Policy control is one reason why operators like to
do this. LMA/HA is the policy enforcement point. We do this today
in Mobile IPv4 as well. For various reasons, the home operator likes
to see the mobile traffic flow through the home anchor point, its
simply for administrative reasons.

>> 8) The protocol creates a delay between the host sends an RS and
>>    when it gets an RA, which could be large (since there could
>>    be packet loss in the exchange that happens between the MAG
>>    and the LMA before the MAG can send the RA).  This is at odds
>>    with other IETF efforts to decrease such delay, e.g. for cases
>>    when one is roaming from one domain to another and using MIPv6,
>>    or for the case when one temporarily loses connectivity and
>>    wants to regain it asap.  The fact that it can adversely affect
>>    these cases isn't called out, just the fact that there may be
>>    a delay (and one has to look in section 7.1 to find it, it's
>>    not mentioned in the overview, which incorrectly shows the
>>    node delaying sending the RS until long after the link is up).
>>

The event that the MAG uses for triggering PMIP signaling on behalf
of a mobile node is typically after receving an ACCESS_AUTH event.
The event could be a signal from the radio network, or an event
after successful L2 authentication. We were bit loose on this
and were showing the RS as the event that triggers PMIP signaling.
We will fix this.

>> 9) The protocol invents another link type numbering space that
>>    IANA has to manage.  It's not clear why the existing ifType
>>    that IANA already manages won't do the job.
>>

Ok. We just need a registry that has all the access technology
types. We will review this.

>> 10) The protocol assumes that the router (MAG) has no addresses
>>    in the on-link prefix, but that it does have a global address
>>    on the same interface.  The first statement violates RFC-4291
>>    section 4.9.1, which requires that the router have the
>>    subnet router anycast address in each on-link prefix.
>>    The second statement seems unnecessary, why can't it just
>>    use the global address of some other interface for sending
>>    messages to the home agent (LMA)?
>>

The address that the MAG uses as the source address in PMIP
signaling is the global address configured on the egress
interface of the MAG. It is not the address on the P2P link
between the MAG and the MN. This address is referred to as
the Proxy-CoA and this is mentioned in the terminology section
and also identified in the illustrations. We will clarify this
to ensure this is clear.

Dave, thanks for your time on this review. !

Regards
Sri

>> -Dave Thaler
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm