Subject: Re: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 06 Oct 2009 11:49:09 -0700

Hello Arnaud,

Thanks for the terrific review and many suggestions.  I have been
owing you a response on the specific questions and issues you
raised.  So, here goes...

Arnaud Ebalard wrote:
>
>>       A Binding Acknowledgement is used to acknowledge receipt of a
>>       Binding Update, if an acknowledgement was requested in the Binding
>>       Update, the binding update was sent to a home agent, or an error
>>       occurred.
>>     
>
> As a binding update sent to a Home Agent must have the A bit set
> (i.e. "an acknowledgement was requested in the Binding Update" as
> stated above), a BA is always sent by the HA. This means the "the
> binding update was sent to a home agent" is redundant in previous
> paragraph.
>   

How about:

                    if an acknowledgement was requested in the Binding
      Update (e.g., the binding update was sent to a home agent), or an
      error occurred.

>
>   
>>    attachment to other sites, resulting in possible unrechability
>>    between the MN and the HA, when unique-local IPv6 routable addresses
>>    are used as care-of addresses.  Also, CNs outside the MN's own site
>>    are not going to be reachable when unique-local IPv6 routable
>>    addresses are used as home addresses.  Therefore, unique-local IPv6
>>    unicast addresses SHOULD NOT be used as home or care-of addresses.
>>     
>
> If this is the only address usable as a CoA for the node, it is worth
> trying to use it. I tried and found some discussion on the list about
> this topic but failed (I thought it had been discussed). Can someone
> give me some feedback on the reason it is that way?
>   

How about:

                                                  unique-local IPv6
   unicast addresses SHOULD NOT be used as home or care-of addresses
   if any other addresses are available to the mobile node.

>
>
>    As with all IPsec security associations in this specification, manual
>    configuration of security associations MUST be supported.  The used
>    shared secrets MUST be random and unique for different mobile nodes,
>    and MUST be distributed off-line to the mobile nodes.
>
>    Automatic key management with IKE [7] MAY be supported.  When IKE
>   
>
> Any reason not to add a link to IKEv2 spec?
>   

Will do.

>   
>>    Reference [15] contains a more detailed description and examples on
>>    using IPsec to protect the communications between the mobile node and
>>    the home agent.
>>     
>
> What about adding a link to 4877 too?
>   
O.K.
>
>   
>> 5.3.  Dynamic Home Agent Address Discovery
>>
>>    No security is required for dynamic home agent address discovery.
>>     
>
> May be it is the way I understanded it but this sounds like "no security
> is needed". It should sounds like "No security is provided for that
> mechanism". 
>   

As I remember the discussion, it was more properly represented by the
existing text.  Perhaps opinions have changed in the meantime since this
was originally written.  It's been a while, but I think the sense of the 
discussion
at that time was that DHAAD would only be used in environments where
security was not a problem.
>   
>
>
>   
>>    This type provides the necessary functionality but does not open
>>    vulnerabilities discussed in Section 15.1.
>>     
>
> What about adding a link to RFC5095 here, i.e. "Section 15.1 and
> [RFC5095]".
>   

O.K.

>   
>> 6.1.7.  Binding Update Message
>>
>>    The Binding Update (BU) message is used by a mobile node to notify
>>    other nodes of a new care-of address for itself.  Binding Updates are
>>    sent as described in Section 11.7.1 and Section 11.7.2.
>>
>>    The Binding Update uses the MH Type value 5.  When this value is
>>    indicated in the MH Type field, the format of the Message Data field
>>    in the Mobility Header is as follows:
>>
>>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>                                        |          Sequence #           |
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>        |A|H|L|K|        Reserved       |           Lifetime            |
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>        |                                                               |
>>        .                                                               .
>>        .                        Mobility options                       .
>>        .                                                               .
>>        |                                                               |
>>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>    Acknowledge (A)
>>
>>       The Acknowledge (A) bit is set by the sending mobile node to
>>       request a Binding Acknowledgement (Section 6.1.8) be returned upon
>>       receipt of the Binding Update.
>>
>>    Home Registration (H)
>>
>>       The Home Registration (H) bit is set by the sending mobile node to
>>       request that the receiving node should act as this node's home
>>       agent.  The destination of the packet carrying this message MUST
>>       be that of a router sharing the same subnet prefix as the home
>>       address of the mobile node in the binding.
>>     
>
> This prevents the MN to communicates with the HA on another
> interface. Is there any reason for that limitation, i.e. not having a
> SHOULD here instead of a MUST. Or I should ask, what is the reason to
> have a MUST here.
>   

I couldn't think of a reason against using SHOULD instead of MUST.
However, I don't remember anyone asking for this feature, and unless
there is a reason to make the change, I would not relax that mandate.

> For instance, the main connectivity of the home agent can be provided by
> a given provided (symmetric line) while the MN are on a subnet for which
> the prefix is provided by another provider. That way, the download
> bandwidth used by the MNs is not shared with the upload bandwidth:
>
>      ISP1 -- home subnet ---[HA]--- ISP2
>   
In this picture, do you mean that the MN has a home address from
ISP2, and it should be able to send a packet to the home agent via
a destination address from ISP1?  Seems a bit roundabout to me,
but still it could be made workable, and one could establish a
cost structure for the network which would favor the alternate
control signal path.  But are there really such networks that need
this solution?
>
>>       ...
>>    The deletion of a binding can be indicated by setting the Lifetime
>>    field to 0 and by setting the care-of address equal to the home
>>    address.  In deletion, the generation of the binding management key
>>    depends exclusively on the home keygen token, as explained in
>>    Section 5.2.5.  (Note that while the senders are required to set both
>>    the Lifetime field to 0 and the care-of address equal to the home
>>    address, Section 9.5.1 rules for receivers are more liberal, and
>>    interpret either condition as a deletion.)
>>     
>
> For the records: 
>
> There is no rationale for explicitly providing different behavior for
> senders and receivers. The various rules associated with what can and
> should be done on that aspects are spread at various places in the
> spec. I already discussed that in draft-ebalard-mext-hld-security-00.
>   

I'm not sure what to do to resolve your issue.  Your first sentence is, 
in the
abstract, incorrect; for example, we are exhorted to be conservative in what
we send, but liberal in what we accept.  So, a bit more justification 
would be
needed before making any such wholesale changes.  I'm reluctant to absorb
text from your draft without more discussion.   Do you propose any specific
changes for this matter?

>
>   
>
>
>>
>>    Home Address
>>
>>       The Home Address of the destination Mobile Node.
>>
>>    For a type 2 routing header, the Hdr Ext Len MUST be 2.  The Segments
>>    Left value describes the number of route segments remaining; i.e.,
>>    number of explicitly listed intermediate nodes still to be visited
>>    before reaching the final destination.  Segments Left MUST be 1.  The
>>    ordering rules for extension headers in an IPv6 packet are described
>>    in Section 4.1 of RFC 2460 [8].  The type 2 routing header defined
>>    for Mobile IPv6 follows the same ordering as other routing headers.
>>    If both a type 0 and a type 2 routing header are present, the type 2
>>    routing header should follow the other routing header.  A packet
>>    containing such nested encapsulation should be created as if the
>>    inner (type 2) routing header was constructed first and then treated
>>    as an original packet by the outer (type 0) routing header
>>    construction process.
>>     
>
> Considering deprecation of RH0 by RFC 5095, it may be worth modifying
> this paragraph to reflect that, for instance by stating that except
> otherwise specified, the RH2 should be the last one in the set of RH
> (i.e. removing the reference to the specific 'Type 0').
>   

O.K.  How about:

                                       The type 2 routing header defined
   for Mobile IPv6 follows the same ordering as other routing headers.
   If another routing header is present along with a type 2 routing header,
   the type 2 routing header should follow the other routing header.  A packet
   containing such nested encapsulation should be created as if the
   inner (type 2) routing header was constructed first and then treated
   as an original packet by header construction process for the other
   routing header.

>
>
>
>>                              ......                         when
>>    sending unsolicited multicast Router Advertisements more frequently
>>    than the limit specified in RFC 4861 [20], the sending router need
>>     
>
> s/RFC 4861 [20]/Neighbor Discovery [20]/
>
> IMHO, this is easier to read. Note that there are various places in the
> document where the replacement should be done.
>   

I'd be happier if you could point them out.

>
>   
>> 8.4.  IPv6 Home Agents
>>
>>    In order for a mobile node to operate correctly while away from home,
>>    at least one IPv6 router on the mobile node's home link must function
>>    as a home agent for the mobile node.  The following additional
>>    requirements apply to all IPv6 routers that serve as a home agent:
>>
>>    o  Every home agent MUST be able to maintain an entry in its Binding
>>       Cache for each mobile node for which it is serving as the home
>>       agent (Section 10.1 and Section 10.3.1).
>>
>>    o  Every home agent MUST be able to intercept packets (using proxy
>>       Neighbor Discovery [20]) addressed to a mobile node for which it
>>     
>
> No opinion on whether this is a good idea or not, but probably worth
> asking: what about also adding a reference to RFC 4389 (experimental
> doc)?
>   

What is the advantage of making the citation?

>
>>
>>    o  The node MAY support stateful address autoconfiguration mechanisms
>>       such as DHCPv6 [32] on the interface represented by the tunnel to
>>       the home agent.
>>     
>
> How is that supposed to happen/work? Is that to support provisioning of
> *additional* addresses (not HoA) from the Home Network? It is unclear.
>   

What if (a) the mobile node gets an address from DHCP and then
(b) runs IKE with its home agent?  How should the statement be made clearer?

>   
>> 9.  Correspondent Node Operation
>>
>> 9.1.  Conceptual Data Structures
>>
>>    ...
>>    o  A lifetime value, indicating the remaining lifetime for this
>>       Binding Cache entry.  The lifetime value is initialized from the
>>       Lifetime field in the Binding Update that created or last modified
>>       this Binding Cache entry.
>>     
>
> Lifetime may be the one sent in the BA in fact or am i missing sth?
>   

I reckon so.  I could add a sentence:

   o  A lifetime value, indicating the remaining lifetime for this
      Binding Cache entry.  The lifetime value is initialized from the
      Lifetime field in the Binding Update that created or last modified
      this Binding Cache entry.  The correspondent node MAY select a
      smaller lifetime for the Binding Cache entry, and supply that value
      to the mobile node in the Binding Acknowledgment message.

>> 9.5.1.  Receiving Binding Updates
>>
>>    Before accepting a Binding Update, the receiving node MUST validate
>>    the Binding Update according to the following tests:
>>
>>    ... 
>>    When the Home Registration (H) bit is not set, the following are also
>>    required:
>>
>>    ....
>>
>>    If the Home Registration (H) bit is set, the Nonce Indices mobility
>>    option MUST NOT be present.
>>     
>
> The binding auth data must not be present either in that case.
>   
...?  I don't think that is true.

>
>>
>>    o  If the Lifetime specified in the Binding Update is zero, then this
>>       is a request to delete the cached binding for the home address.
>>       If the Home Registration (H) bit is set in the Binding Update, the
>>       Binding Update is processed according to the procedure specified
>>       in Section 10.3.1; otherwise, it is processed according to the
>>       procedure specified in Section 9.5.2.
>>     
>
>
> That item deals with *deletion* but points to sections associated with
> requests to cache a binding (10.3.1 and 9.5.2). The first sentence
> should be "If the Lifetime specified in the Binding Update is *not*
> zero, then this is a request to *cache a binding* for the home
> address". Otherwise, it does not make sense and is duplicate w/ next
> item 
>   

Good catch!  I reckon you are correct.  I wonder how that bug
stayed in the specification for so long!

>
>
>   
>> 10.3.1.  Primary Care-of Address Registration
>>
>>    When a node receives a Binding Update, it MUST validate it and
>>    determine the type of Binding Update according to the steps described
>>    in Section 9.5.1.  Furthermore, it MUST authenticate the Binding
>>    Update as described in Section 5.1.  An authorization step specific
>>    for the home agent is also needed to ensure that only the right node
>>    can control a particular home address.  This is provided through the
>>    home address unequivocally identifying the security association that
>>    must be used.
>>
>>    This section describes the processing of a valid and authorized
>>    Binding Update when it requests the registration of the mobile node's
>>    primary care-of address.
>>
>>    To begin processing the Binding Update, the home agent MUST perform
>>    the following sequence of tests:
>>
>>    o  If the node implements only correspondent node functionality, or
>>       has not been configured to act as a home agent, then the node MUST
>>       reject the Binding Update.  The node MUST also return a Binding
>>       Acknowledgement to the mobile node, in which the Status field is
>>       set to 131 (home registration not supported).
>>
>>    o  Else, if the home address for the binding (the Home Address field
>>       in the packet's Home Address option) is not an on-link IPv6
>>       address with respect to the home agent's current Prefix List, then
>>       the home agent MUST reject the Binding Update and SHOULD return a
>>       Binding Acknowledgement to the mobile node, in which the Status
>>       field is set to 132 (not home subnet).
>>
>>    o  Else, if the home agent chooses to reject the Binding Update for
>>       any other reason (e.g., insufficient resources to serve another
>>       mobile node as a home agent), then the home agent SHOULD return a
>>       Binding Acknowledgement to the mobile node, in which the Status
>>       field is set to an appropriate value to indicate the reason for
>>       the rejection.
>>
>>    o  A Home Address destination option MUST be present in the message.
>>       It MUST be validated as described in Section 9.3.1 with the
>>       following additional rule.
>>     
>
> When coming back home, the Home Address destination option may be
> omitted in fact.
>   

But this is a section dealing with registering a care-of-address, not 
deregistering it.

>
>
>   
>>    attempt to intercept packets on the mobile node's home link that are
>>    addressed to the mobile node.
>>
>>    In order to do this, when a node begins serving as the home agent it
>>    MUST multicast onto the home link a Neighbor Advertisement message
>>    [20] on behalf of the mobile node.
>>     
>
> As specified in section 10.3.1:
>
>    Unless this home agent already has a binding for the given home
>    address, the home agent MUST perform Duplicate Address Detection [21]
>    on the mobile node's home link before returning the Binding
>    Acknowledgement.
>
> So, the last sentence should be modified to indicate that the NA is sent
> only after that initial DAD.
>   

One could argue that the node doesn't begin serving as a home agent
until after DAD is finished.  But, if you would like to propose some
better text, I am open to suggestion.

>
>>
>>    While a node is serving as a home agent for some mobile node, the
>>    home agent uses IPv6 Neighbor Discovery [20] to intercept unicast
>>    packets on the home link addressed to the mobile node.  In order to
>>    intercept packets in this way, the home agent MUST act as a proxy for
>>    this mobile node and reply to any received Neighbor Solicitations for
>>    it.  When a home agent receives a Neighbor Solicitation, it MUST
>>    check if the Target Address specified in the message matches the
>>    address of any mobile node for which it has a Binding Cache entry
>>    marked as a home registration.
>>     
>
> Need for a link to 4389 here too?
>   

I still didn't exactly see why...

>   
>> 10.4.2.  Processing Intercepted Packets
>>
>>    For any packet sent to a mobile node from the mobile node's home
>>    agent (in which the home agent is the original sender of the packet),
>>    the home agent is operating as a correspondent node of the mobile
>>    node for this packet and the procedures described in Section 9.3.2
>>    apply.  The home agent then uses a routing header to route the packet
>>    to the mobile node by way of the primary care-of address in the home
>>    agent's Binding Cache.
>>
>>    While the mobile node is away from home, the home agent intercepts
>>    any packets on the home link addressed to the mobile node's home
>>    address, as described in Section 10.4.1.  In order to forward each
>>    intercepted packet to the mobile node, the home agent MUST tunnel the
>>    packet to the mobile node using IPv6 encapsulation [9].  When a home
>>    agent encapsulates an intercepted packet for forwarding to the mobile
>>    node, the home agent sets the Source Address in the new tunnel IP
>>    header to the home agent's own IP address and sets the Destination
>>    Address in the tunnel IP header to the mobile node's primary care-of
>>    address.  When received by the mobile node, normal processing of the
>>    tunnel header [9] will result in decapsulation and processing of the
>>    original packet by the mobile node.
>>
>>    However, packets addressed to the mobile node's link-local address
>>    MUST NOT be tunneled to the mobile node.  Instead, these packets MUST
>>    be discarded and the home agent SHOULD return an ICMP Destination
>>    Unreachable, Code 3, message to the packet's Source Address (unless
>>    this Source Address is a multicast address).
>>     
>
> I am certainly missing something here, but what is the point for the HA
> in defending the IP then?
>   

So that no other node will steal the mobile node's link-local address.  
The mobile
node would like to have it back when it returns to the home network.
>   
>>    where MaxMobPfxAdvInterval is as defined in Section 12.  Then compute
>>    the final delay for the advertisement:
>>
>>
>>      RAND_ADV_DELAY = MinMobPfxAdvInterval +
>>            (rand() % abs(MaxScheduleDelay - MinMobPfxAdvInterval))
>>
>>    Here rand() returns a random integer value in the range of 0 to the
>>    maximum possible integer value.  This computation is expected to
>>    alleviate bursts of advertisements when prefix information changes.
>>    In addition, a home agent MAY further reduce the rate of packet
>>    transmission by further delaying individual advertisements, when
>>    necessary to avoid overwhelming local network resources.  The home
>>    agent SHOULD periodically continue to retransmit an unsolicited
>>    Advertisement to the mobile node, until it is acknowledged by the
>>    receipt of a Mobile Prefix Solicitation from the mobile node.
>>     
>
> seems weird.
>   

As I remember, this was considered very cool at the time.
I don't remember why, but unless there is a need for change
I'd rather not go back and figure it out.

>   
>> 11.  Mobile Node Operation
>>
>> 11.1.  Conceptual Data Structures
>>
>>  
>>
>>    o  The remaining lifetime of that binding.  This lifetime is
>>       initialized from the Lifetime value sent in the Binding Update and
>>       is decremented until it reaches zero, at which time this entry
>>       MUST be deleted from the Binding Update List.
>>     
>
> Updated by the BA.
>
>   
But, I think the BA can only decrease the lifetime, right?  So it would
still be a further decrementation.

>
>> 11.3.2.  Interaction with Outbound IPsec Processing
>>
>> ...
>>
>>    The Key Management Mobility Capability (K) bit in Binding Updates and
>>    Acknowledgements can be used to avoid the need to rerun IKE upon
>>    movements.
>>     
>
> Considering the mechanism is implemented and such an interface needed to
> support that, 3775bis could at least point MIGRATE doc given below as an
> informational reference document. This clarifies the need and gives a
> possible solution.
>
>  http://tools.ietf.org/html/draft-ebalard-mext-pfkey-enhanced-migrate-00
>   

Can we do this safely without having the citation to be
considered normative?

>   
>
>
>   
>> 11.4.3.  Receiving Mobile Prefix Advertisements
>>
>>    Section 10.6 describes the operation of a home agent to support boot
>>    time configuration and renumbering a mobile node's home subnet while
>>    the mobile node is away from home.  The home agent sends Mobile
>>    Prefix Advertisements to the mobile node while away from home, giving
>>    "important" Prefix Information options that describe changes in the
>>    prefixes in use on the mobile node's home link.
>>
>>    The Mobile Prefix Solicitation is similar to the Router Solicitation
>>    used in Neighbor Discovery [20], except it is routed from the mobile
>>    node on the visited network to the home agent on the home network by
>>    usual unicast routing rules.
>>
>>    When a mobile node receives a Mobile Prefix Advertisement, it MUST
>>    validate it according to the following test:
>>
>>    o  The Source Address of the IP packet carrying the Mobile Prefix
>>       Advertisement is the same as the home agent address to which the
>>       mobile node last sent an accepted home registration Binding Update
>>       to register its primary care-of address.  Otherwise, if no such
>>       registrations have been made, it SHOULD be the mobile node's
>>       stored home agent address, if one exists.  Otherwise, if the
>>       mobile node has not yet discovered its home agent's address, it
>>       MUST NOT accept Mobile Prefix Advertisements.
>>
>>    o  The packet MUST have a type 2 routing header and SHOULD be
>>       protected by an IPsec header as described in Section 5.4 and
>>       Section 6.8.
>>
>>    o  If the ICMP Identifier value matches the ICMP Identifier value of
>>       the most recently sent Mobile Prefix Solicitation and no other
>>       advertisement has yet been received for this value, then the
>>       advertisement is considered to be solicited and will be processed
>>       further.
>>
>>       Otherwise, the advertisement is unsolicited, and MUST be
>>       discarded.  In this case the mobile node SHOULD send a Mobile
>>       Prefix Solicitation.
>>     
>
> I tried and raise a clarification on that point:
>
> See   http://permalink.gmane.org/gmane.ietf.mip6/9433
>
> but got no response. IMHO, clarifying things a bit would help.
>   

How about:

      Otherwise, the advertisement is unsolicited, and MUST be
      discarded.  In this case the mobile node SHOULD send a Mobile
      Prefix Solicitation, using the same ICMPv6 identifier that was
      used for the previous Solicitation.

>
>> 11.5.2.  Home Link Detection
>>
>>    When an MN detects that it has arrived on a new link using the
>>    movement detection algorithm in use (Section Section 11.5.1,) it
>>    performs the following steps to determine if it is on the home link.
>>
>>    o  The MN performs the procedure described in Section 11.5.2x and
>>     
>
>                                                     s/11.5.2x/11.5.2/
>
> Then, it seems that 11.5.2 is current section. Weird.
>
>   

I reckon this ought to be 11.5.3.

>>       configures an address.  It also keeps track of all the on-link
>>       prefix(es) received in the RA along with their prefix lengths.
>>
>>    o  If the home prefix has not been statically configured the MN uses
>>       some form of bootstrapping procedure (e.g.  RFC5026 [25]) to
>>       determine the home prefix.
>>
>>    o  Given the availability of the home prefix, the MN checks whether
>>       or not the home prefix matches one of the prefixes received in the
>>       RA.  If it does, the MN concludes that it has returned home.
>>     
>
> It should be stated here or in the "Security Considerations" section
> that this procedure is insecure and may have security impact, as we rely
> on basic ND and undergo associated threats. This is documented:
>
> http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00
>   

I could put some advice in the Security Considerations section and a
cross reference here.  If you happen to have a short paragraph of text that
you wanted to contribute for that purpose, it would be appreciated.
>   
>
>
>   
>>    the previously registered care-of address.
>>
>>    In this home registration, the mobile node MUST set the Acknowledge
>>    (A) and Home Registration (H) bits, set the Lifetime field to zero,
>>    and set the care-of address for the binding to the mobile node's own
>>    home address.  The mobile node MUST use its home address as the
>>    source address in the Binding Update.
>>     
>
> Processing for receiver allows either lft=0 or CoA == HoA; so what's the
> point in that MUST.
>   

Well, it's been there for a long time, and I don't know if it
would be worthwhile to change.  It might break various
interoperability tests, for one thing.

>
>   
>
>   
>> 15.  Security Considerations
>>     
>
> Considering this is documented:
>
> http://tools.ietf.org/html/draft-ebalard-mext-hld-security-00
>
> the possible specific insecurity of the Home Link Detection mechanism
> could be referenced in that section.
>
>   
>
>
>   
>> 15.7.  Tunneling via the Home Agent
>>
>>
>>    When site local home addresses are used, reverse tunneling can be
>>    used to send site local traffic from another location.
>>    Administrators should be aware of this when allowing such home
>>    addresses.  In particular, the outer IP address check described above
>>    is not sufficient against all attackers.  The use of encrypted
>>    tunnels is particularly useful for these kinds of home addresses.
>>     
>
> In previous paragraph, reference to site local (deprecated) should be
> replaced by a reference to Unique Local Addresses (RFC4193).
>   

O.K.

>   
>> 16.  Contributors
>>
>>    Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark,
>>    and Michael Thomas worked on the return routability protocols
>>    eventually led to the procedures used in this protocol.
>>     
>
> In previous sentence, s/worked/work/ 
>
>
>   

I think some other people were involved -- and this was a very 
contentious time
in the working group.

How about:

   Work done by Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander,
   Erik Nordmark, and Michael Thomas on the return routability protocols
   shaped the procedures used in this protocol.

Regards,
Charlie P.

---

From: [email-masked] (Arnaud Ebalard)
Date: Wed, 07 Oct 2009 11:42:50 +0200

Hi Charles,

> owing you a response on the specific questions and issues you

Well, thanks for your work too. Iterating over and over on the spec must
be a bit painful at some point. More fun below ... ;-)

Note that I did not remove any text from your reply so that you can
cross-check.

>      Update (e.g., the binding update was sent to a home agent), or an

fine with me.

>   if any other addresses are available to the mobile node.

I think it is better. But I wonder if there is a need to make some
specific case for ULA. Basically, one would expect the MN to apply some
kind of RFC 3484 logic to select the CoA to be used as source address
for the connection with the HA (based on the HA address). I don't think
there is a need to go that far in the description but I also don't think
there is a need to make a specific case about ULA. IMHO, CoA selection
is a local matter for the MN.

> was originally written.  It's been a while, but I think the sense of
> the discussion at that time was that DHAAD would only be used in
> environments where security was not a problem.

ok.

> a destination address from ISP1?

No. Sorry for the unclear picture. The MN has a home address from ISP1
(home network prefix is from the prefix provided by ISP1) but connects
from a foreign network to the HA which is reachable from outside on an
address from ISP2.  

> control signal path.  But are there really such networks that need

Mine looks like what I describe above for the following reason: 

 - on ISP2, I have a SDSL (which costs a leg)
 - on ISP1, I have an ADSL (cheap and with good downlink)

When I am in a foreign network, downloading sth consume some upload
bandwidth from my SDSL and some download bandwidth from my ADSL.

If my HA address and my Home Network prefix were in a prefix provided by
ISP1 (ADSL), I would have a very limited upload bandwidth (i.e. download
as a MN).

If both were in a prefix provided by ISP2, downloading something as a MN
would saturate both directions on the SDSL.

Another example were it may be useful: a community of MN that are not
expected to speak *with* the outside world. In that case, you can use a
ULA prefix for the Home Net. But you want to allow the MN to communicate
*from* the outside world, i.e. from foreign networks outside the site.

I would have to check the spec, but I think the only thing that would
prevent to relax that MUST is the fact that the Home Agent List for
DHAAD is built using the HA address provided in the PIO in RA (section
7.2). Home Link Detection mechanism does not use the HA address but the
Home Prefix. 

I let you decide.

> I'm not sure what to do to resolve your issue.  Your first sentence
> is, in the abstract, incorrect; for example, we are exhorted to be
> conservative in what we send, but liberal in what we accept. 

Yes, but this does not mean that we MUST create different logics for
sender and receiver. For instance, sender setting reserved field to 0
and receiver ignoring it is ok. But that specific HoA == CoA case w/
lft != 0 seems weird.

> So, a bit more justification would be needed before making any such
> wholesale changes.  I'm reluctant to absorb text from your draft
> without more discussion.   Do you propose any specific changes for
> this matter? 

As Marcelo pointed out, I don't think that the changes would fit in the
scope of rfc3775bis improvements because it would probably change the
expected behavior. I think adding a reference to hld-sec draft in the
security consideration section would help but I let you and the chairs
decide if it would be useful.

>   as an original packet by header construction process for the other

Seems clear (as far as explaining routing header logic can be ;-) ).

> I'd be happier if you could point them out.

No problem:

Section 6.7 Page 62, first paragrah:

   The Mobile Prefix Solicitation messages may have options.  These
   options MUST use the option format defined in RFC 4861 [20].

Section 6.8 Page 64, first paragraph:

   The Mobile Prefix Advertisement messages may have options.  These
   options MUST use the option format defined in RFC 4861 [20].

Section 6.8 Page 64, second paragraph of Prefix Information descr:

      The Prefix Information option is defined in Section 4.6.2 of RFC
      4861 [20], with modifications defined in Section 7.2 of this

Section 7.2 Page 67, middle of first paragraph:

   than the limit specified in RFC 4861 [20], the sending router need
   not include all options in each of these Advertisements.  However, in

Section 7.5 Page 71, two occurences in first paragraph:

   are available MUST NOT default to them, and SHOULD default to values
   specified in RFC 4861.  Knowledge of the type of network interface

  and

   can cause considerable overhead.  Routers SHOULD adhere to the
   intervals specified in RFC 4861 [20], if this overhead is likely to

Section 7.5 Page 71, last paragraph:

   Note that according to RFC 4861 [20], AdvDefaultLifetime is by
   default based on the value of MaxRtrAdvInterval.  AdvDefaultLifetime

Section 10.6.1 Page 106, two occurences in last paragraph of that sect.: 

   itself and other home agents on the home link.  In RFC 4861 [20] it
   is acceptable for two routers to advertise different sets of prefixes

  and

   All other comparisons of Router Advertisements are as specified in
   Section 6.2.7 of RFC 4861.

Section 11.5.1 Page 126, first paragraph:

   to discover routers and prefixes on the new link, as described in
   Section 6.3.7 of RFC 4861 [20].

Section 13 Page 145, third paragraph:

   The value MinDelayBetweenRAs overrides the value of the protocol
   constant MIN_DELAY_BETWEEN_RAS, as specified in RFC 4861 [20].  This

> What is the advantage of making the citation?

It complements the content of Section 7.2.8 of RFC 4861 with additional
information on ND Proxy. At least, it does not cost much to add a
reference to that experimental document so that people are aware that
Proxy-ND does not work out of the box with all kinds of links.

> (b) runs IKE with its home agent?

Sorry, I do not understand what you mean. Can you describe more
precisely the steps? The tunnel does not even exist prior to the binding
(which require the HoA) so I don't see how this can work.

>  How should the statement be made clearer? 

Well, I don't even see how this can work so at the moment, I would
remove that item.

>      to the mobile node in the Binding Acknowledgment message.

good.

>>>    ...    When the Home Registration (H) bit is not set, the
>>> following are also
>>>    required:
>>>
>>>    ....
>>>

H bit set => receiver of the BU is the MN's HA (See section
6.1.7). Binding Auth Data with the HA does not make sense because BU is
IPsec protected.

The misleading thing with that section is that it is for correspondent
node behavior but is also used to describe the steps performed by the
HA. So, IMHO:

       If the Home Registration (H) bit is set, the Nonce Indices and
       Binding Auth Data mobility options MUST NOT be present.

> stayed in the specification for so long!

;-)

> But this is a section dealing with registering a care-of-address, not

Yes, but second paragraph of the next section (10.3.2, "Primary Care-of
Address De-Registration") starts with the following:

        "A Binding Update is validated and authorized in the manner
        described in the previous section; note that when the mobile
        node de-registers when it is at home, it MAY choose to omit the
        Home Address destination option, in which case the mobile node's
        home address is the source IP address of the de-registration
        Binding Update." 

So the content of section 10.3.1 also applies to dereg BU. But in the
end, rereading that paragraph, this seems clear so drop my comment.

> better text, I am open to suggestion.

What about?:

  In order to do this, when a node begins serving as the home agent it
  MUST multicast onto the home link a Neighbor Advertisement message
  [20] on behalf of the mobile node. This can only be done after having
  verified using DAD that the home address is not already in use on the
  Home Network (as specified in Section 10.3.1).

> I still didn't exactly see why...

For the reader to be aware it exists. But this is not critical.

> The mobile node would like to have it back when it returns to the home
> network.

Thanks for the clarification.

> I'd rather not go back and figure it out.

ok. Let's keep it that way.

> still be a further decrementation.

yes, exactly.

> Can we do this safely without having the citation to be

What about changing the K bit description in 6.1.7 from

   Key Management Mobility Capability (K)

      If this bit is cleared, the protocol used for establishing the
      IPsec security associations between the mobile node and the home
      agent does not survive movements.  It may then have to be rerun.
      (Note that the IPsec security associations themselves are expected
      to survive movements.)  If manual IPsec configuration is used, the
      bit MUST be cleared.

to that:

   Key Management Mobility Capability (K)

      If this bit is cleared, the protocol used for establishing the
      IPsec security associations between the mobile node and the home
      agent does not survive movements.  It may then have to be
      rerun. If manual IPsec configuration is used, the bit MUST be
      cleared. 

      Note that the transport mode IPsec security associations
      themselves are expected to survive movements. A possible solution
      regarding the update of IKE SA (Phase 1 for IKEv1, IKE_SA for
      IKEv2) update and optional tunnel mode IPsec SP/SA update is
      described in [MIGRATE].

>      used for the previous Solicitation.

ok.

> you wanted to contribute for that purpose, it would be appreciated.

Is that ok?:

  The Home Link Detection mechanism described in section 11.5.2 and used
  by the MN to detect it is at home relies on Neighbor Discovery
  [20]. When IPsec is used by the MN for protecting data traffic
  exchanged with the Home Agent from foreign networks, relying on this
  mechanism may have security implications. This is discussed in [hld-sec].

> interoperability tests, for one thing.

Well, if a HA receives a dereg BU with the lft not set to 0, then it is
from a non compliant implementation. And if the HA does not accept such
a BU sent by a non-compliant implementation, it would fail an
interoperability test.

Also note that for the MN to send a BU with the HoA as source address in
the IPv6 header (i.e. no HAO), this requires the MN to have detected it
is on its Home Network. In that case, it would purposely not set the
lifetime to 0 do deregister?

But I agree that this is some kind of historical weirdness we need to
keep.

> contentious time in the working group.

Sorry, I may have been unclear. The first sentence has 2 verbs: 'worked'
and 'led' but only one subject.

I think there is either a missing 'which' or 'worked' need to be changed
in 'work' i.e. one of the following would be valid:

    Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark,
    and Michael Thomas worked on the return routability protocols which
    eventually led to the procedures used in this protocol.

or 

    Tuomas Aura, Mike Roe, Greg O'Shea, Pekka Nikander, Erik Nordmark,
    and Michael Thomas work on the return routability protocols
    eventually led to the procedures used in this protocol. 

>   shaped the procedures used in this protocol.

that would be ok too.

Cheers,

a+

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 08 Oct 2009 12:17:10 -0700

Hello Vijay,

Strangely, there doesn't seem to be anything in the
document that should produce the erroneous occurrences
of "Section section" or "Section section".  Maybe it is a
bug with xml2rfc.  I'll scan the output and make the
repairs manually.

If anyone else has information about this, please let
me know.

Regards,
Charlie P.

Vijay Devarapalli wrote:
> I reviewed the document. It is ready to be sent to the IESG. 
>
> I have a couple of minor comments.
>
> There are a few instances of "Section Section" in the document. I saw
> them in sections 10.3.2, 11.3.6 and 11.5.2.
>
> The following needs a re-write. 
>
>    Binding Error
>
>       The Binding Error is used by the correspondent node or the home
>       agent to signal an error related to mobility, such as an
>       inappropriate attempt to use the Home Address destination option
>       without an existing binding, or when an unrecognized Mobility
>       Header is received.
>
> The HA sends a binding error to the mobile node only when it sees an
> unrecognized Mobility Header Type. So I suggest re-writing it as
>
>    Binding Error
>
>       The Binding Error is used by the correspondent node to signal an 
>       error related to mobility, such as an inappropriate attempt to use
>
>       the Home Address destination option without an existing binding. 
>       The Binding Error message is also used by the Home Agent to signal
>
>       an error to the mobile node, when it receives an unrecognized 
>       Mobility Header Message Type from the mobile node.
>
> Vijay
>
>   
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of Laganier, Julien
>> Sent: Wednesday, August 05, 2009 8:20 AM
>> To: [email-masked]
>> Subject: [MEXT] [WGLC] RFC 3775 bis / draft-ietf-mext-rfc3775bis
>>
>> Folks,
>>
>> As discussed during the MEXT session in IETF-75 we're issuing 
>> a two weeks WGLC on RFC 3775 bis 
>> <http://tools.ietf.org/html/draft-ietf-mext-rfc3775bis-04> 
>> that will follow the two rules below:
>>
>> - this WGLC is NOT intended for re-opening discussions on 
>> issues that were resolved during the revision process neither 
>> for bringing up new issues. 
>>
>> - this WGLC is intended to be sanity check to see whether the 
>> various changes we agreed to made fit together. Editorial 
>> corrections are also welcome.
>>
>> Please review the specification and post a message to the 
>> mailing list if you think the document is ready to be 
>> forwarded to IESG before 2009-08-15 6:00PM PST.
>>
>> Thank you for your support.
>>
>> --julien & Marcelo, MEXT chairs
>>
>> _______________________________________________
>> MEXT mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mext
>>
>>     
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>
>
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 08 Oct 2009 12:41:14 -0700

Hello Vijay,

Thanks for these comments.  I have used your suggested
text.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 08 Oct 2009 13:12:56 -0700

Hello Ryuji,

Thanks for your review.

Ryuji Wakikawa wrote:
> Hi Charlie and all
>
> I reviewed this document and support the current version.
> It's ready to be sent to IESG.
>
> - In Appendix A, A4 and A5 are outdated future things, they were 
> solved by bootstraping RFCs!?

I updated one of the cross-references in the main text to refer to the
bootstrapping RFC.  I think some of the other items described as future
work are also done.  I'll try to go through them today.

>
> The next two comments have low priority, but they are just for better 
> readability.
>
> - Although there is the reference entry of RFC4225, it is not cited 
> anywhere in the text body.
> Should we refer to it somewhere in the text body? Maybe in section 5.2?

I put the citation just after the cross-reference to Section 15.

>
> - 3.2 Mobile IPv6 Terms
> There is RFC 3753 defining the same terms.
> home address, home subnet prefix, mobile node, L2 handover, foreign 
> subnet prefix, care-of address, home agent are defined in RFC3753
> It's OK to me to keep the same terms here, but adding reference of 
> rfc3753 may help readers.
I did that too, keeping the definitions in the document for convenience.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 08 Oct 2009 13:21:58 -0700

Hello Alex,

I didn't see any text in rfc3775bis that referred to mobile
networks. But if you have a suggestion about where it would
fit, please let me know.

I don't think the spec should attempt to refer to all later
work.  For instance we have MCoA, and Proxy MIP, and
who knows what all variants of SIP mobility and SCTP
mobility and DNS mobility and HIP mobility
and TCP mobility, just to name a few :-)  Before long,
maybe we'll have NAT boxes implementing mobility by
transferring translation contexts :-).  [I have not patented
this :-), go for it!].

Regards,
Charlie P.

Alexandru Petrescu wrote:
> I suggest the draft-3775bis to refer to RFC3963 in some way.
>
> Alex
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 08 Oct 2009 13:29:25 -0700

Hello Patrick and Basavaraj,

Thanks again Patrick for your review.  I have made the
change as you suggested, with the later revision as suggested
by Basavaraj.

Regards,
Charlie P.

Stupar, Patrick wrote:
> Hi all,
>
> I reviewed the draft and I think it is ready to be sent to the IESG.
>
> I have one minor comment on section 11.5.2. 
>
> The text does not cover the case of MN bootstrapping in home link. Here is a proposal:
>
> OLD TEXT
>
> NEW TEXT
>    movement detection algorithm in use (Section 11.5.1) or after bootstrapping, it
>    o  The MN performs the procedure described in Section 11.5.3 and
>       RA.  If it does, the MN concludes that it is connected to the home link.
>
>
>
> Thanks
>
> Patrick
>   
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Laganier, Julien
>> Sent: Friday, August 21, 2009 8:30 PM
>> To: Laganier, Julien; [email-masked]
>> Subject: [MEXT] EXTENDED [WGLC] RFC 3775 bis / draft-ietf-mext-
>> rfc3775bis
>>
>> Greetings,
>>
>> There was only one review of the draft RFC3775bis so far and we need
>> more to send this document to IESG thus we decided to extend the WGLC.
>>
>> Please review the specification and post a message to the mailing list
>> if you think the document is ready to be forwarded to IESG before 2009-
>> 09-11 6:00PM EST.
>>
>> --julien & marcelo, MEXT chairs
>>
>>     
>>> From: [email-masked] [mailto:[email-masked]] On Behalf
>>>       
>> Of
>>     
>>> Laganier, Julien
>>> As discussed during the MEXT session in IETF-75 we're issuing a two
>>> weeks WGLC on RFC 3775 bis <http://tools.ietf.org/html/draft-ietf-
>>>       
>> mext-
>>     
>>> rfc3775bis-04> that will follow the two rules below:
>>>
>>> - this WGLC is NOT intended for re-opening discussions on issues that
>>> were resolved during the revision process neither for bringing up new
>>> issues.
>>>
>>> - this WGLC is intended to be sanity check to see whether the various
>>> changes we agreed to made fit together. Editorial corrections are
>>>       
>> also
>>     
>>> welcome.
>>>
>>> Please review the specification and post a message to the mailing
>>>       
>> list
>>     
>>> if you think the document is ready to be forwarded to IESG before
>>>       
>> 2009-
>>     
>>> 08-15 6:00PM PST.
>>>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 08 Oct 2009 13:54:46 -0700

Charles E. Perkins wrote:
>
> Hello Ahmad,
>
> Thanks for your review.  I'll try to make the
> requested clarifications as follows...
>
> Ahmad Muhanna wrote:
>> I just failed to understand what is the 2nd sentence under section 4.6
>> is trying to say. I see the old text was clearer than the newly modified
>> text. Appreciate your clarification.
>>
>> 4.6.  Unique-Local Addressability
>>
>>    ................................  Mobile nodes may not be aware of
>>    which site they are currently making it hard to prevent accidental
>>    are used as care-of addresses.  ....................................
>>   
>
> If a mobile node tries to use a unique-local address, it could be
> an address belonging to a domain other than the home domain.
> Thus, the MIPv6 signaling would never reach the MN's home
> agent.
>
> Does this match your understanding?  If so, I will try to put in the
> clearer sentences to clarify the meaning of that sentence.

Here is what I put in for this issue:

                   ..................          Mobile nodes may not be
   to distinguish between their home site and the site at which they are
   currently located.  This can make it hard to prevent accidental
   attachment to other sites, because the mobile node might use the ULA
   at another site, which could not be used to successfully send packets
   to the mobile node's HA.  This would result in unreachability between
   the MN and the HA, when unique-local IPv6 routable addresses are used
   as care-of addresses.  Similarly, CNs outside the MN's own site will
   not be reachable when ULAs are used as home addresses.  Therefore,
   unique-local IPv6 unicast addresses SHOULD NOT be used as home or
   care-of addresses when other address choices are available.

I also fixed that wretched typo, "unrechability".

>> Comment No. 2:
>> ==============
>> .........
>> My concern is: the new change reverse the logic completely and despite
>> that, the second sentence in this bullet still reference sections 10.3.1
>> and 9.5.2. where both handles the processing of BU when lifetime is
>> NONZERO!
>>
>> .............................
>>  
>
> I think you are right.  I need to go back and reorganize the bullets.  
> The particular
> bullet you cite would be better as two bullets:
>
>   o  If the Home Registration (H) bit is set in the Binding Update, the
> But this needs to be integrated with the rest of the bullets also.
>
> The previous discussion around this issue was to make the "lifetime == 0"
> alternative to be the authoritative decision point, and to 
> de-emphasize the
> role of "CoA == HoA".

This is the same issue that was later identifed by Arnaud.  I must have
had a brain freeze when inserting the language to carry out the decision
in the last paragraph, or else I just dropped in someone's contributed
text without going and reading all the surrounding context (which is just
another kind of brain freeze).  I remember that was supposed to be an
"easy" revision to the text, sigh.

I'll make sure this is fixed in ...rfc3775bis-05.txt, thanks.

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Thu, 08 Oct 2009 14:12:46 -0700

Hello Rajeev and all,

The .xml file I used now produces good text without the
duplicated "Section".  It had not had the word "Section"
before the <xref> tag, but anyway since everything is
working fine now, the issue is resolved.  And anyway I
will scan the document for the duplication again before
submitting the revised text to the Secretariat.

Which I hope will be today :-)

One possible explanation was that I had actually
fixed the problem before submitting the last revision
[...rfc3775bis-04.txt] to the Secretariat in July, but
that I compiled the wrong version of the .xml and
so the error was unfortunately still present and yet
not to be found in my most recently revised .xml file.

Regards,
Charlie P.

Rajeev Koodli wrote:
> Hi Charlie,
>
> when you reference something simply use <xref target=....> instead of
> "Section <xref target=..>"
>
> May be that will do the trick. Or it's something else..
>
> Regards,
>
> -Rajeev
>
>
>
> On Thu, Oct 8, 2009 at 12:17 PM, Charles E. Perkins
> <[email-masked]> wrote:
>   
>> Hello Vijay,
>>
>>>> As discussed during the MEXT session in IETF-75 we're issuing a two weeks
>>>> WGLC on RFC 3775 bis
>>>> <http://tools.ietf.org/html/draft-ietf-mext-rfc3775bis-04> that will follow
>>>> the two rules below:
>>>>
>>>> changes we agreed to made fit together. Editorial corrections are also
>>>> welcome.
>>>>
>>>> Please review the specification and post a message to the mailing list if
>>>> you think the document is ready to be forwarded to IESG before 2009-08-15
>>>> 6:00PM PST.
>>>>

---

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 09 Oct 2009 08:54:32 +0200

Hi,

>   to distinguish between their home site and the site at which they are

 s/may not be to/may not be able to/

>   care-of addresses when other address choices are available.

I think SHOULD NOT is ok. This leaves some latitude to implementation
specific options, I guess. 

Cheers,

a+

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 09 Oct 2009 11:44:12 -0700

>  s/may not be to/may not be able to/

Fixed.  Thanks!

>>                                                    Therefore,

Yes, it does leave some latitude, but I think correctly captures the
intended level of restriction.

Regards,
Charlie P.

---

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 09 Oct 2009 22:11:59 +0200

Hi,

> intended level of restriction.

I read again the sentence and wonder about the following. Can you give
me your feeling?

It would be to bad (IMHO) if MIPv6 module specifically hardcode the fact
that ULA addresses should not be used and do not provide the ability for
users to modify that default (partial) behavior.

In a previous answer, I had some scenarios in which ULA as CoA or HoA
would be useful. I also had a note about RFC 3484 logic as a basis for
selection.

At the moment, I am still under the impression that ULA are moved aside
more by fear than anything else: if you are on a link inside your site
(or say a satellite office) and you only have an ULA prefix advertised,
what's the problem in giving it a try?

Said differently: an IPv6 node on an ULA-only subnet will try and use it
to reach a native or 6to4 peer. Why would a MN not do that to try and
reach its HA on a native or 6to4 address?

Cheers,

a+

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 09 Oct 2009 13:57:15 -0700

Hello Arnaud,

> users to modify that default (partial) behavior.

I understand that you may be asking for the following logic:
- If ULA is the only address available, it SHOULD be used
- If another address is available the ULA SHOULD NOT be used.

Is that correct?

Regards,
Charlie P.

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 09 Oct 2009 14:14:01 -0700

Hello Arnaud,

I have made the changes as we have discussed.
Additional comments inline below:

> is needed". It should sounds like "No security is provided for that

I replaced this sentence by the following:

   Dynamic home agent address discovery has been designed for use in
   deployments where security is not needed.  For this reason, no
   security solution is provided in this document for dynamic home agent
   address discovery.

>      ISP1 -- home subnet ---[HA]--- ISP2

I am willing to change the MUST to a SHOULD, since the message is
secure and the mobile node ought to be able to decide its fate.  But,
I would only do so if this seemingly slight change were approved by
the working group.  I think it goes beyond the kinds of clarifications and
improvements I can unilaterally decide to do.

>
>>
>>    In a Router Advertisement, a home agent MUST, and all other routers
>>    MAY, include at least one Prefix Information option with the Router
>>    Address (R) bit set.  Neighbor Discovery specifies that, if including
>>    all options in a Router Advertisement causes the size of the
>>    Advertisement to exceed the link MTU, multiple Advertisements can be
>>    sent, each containing a subset of the options [20].  Also, when

O.K.  In this particular paragraph, the same document was cited twice, but
in two different ways stylistically.  I think it would be better like this:

   In a Router Advertisement, a home agent MUST, and all other routers
   MAY, include at least one Prefix Information option with the Router
   Address (R) bit set.  Neighbor Discovery (RFC 4861 [20]) specifies
   that, when including all options in a Router Advertisement causes the
   size of the Advertisement to exceed the link MTU, multiple
   Advertisements can be sent, each containing a subset of the Neighbor
   Discovery options.  Also, when sending unsolicited multicast Router
   Advertisements more frequently than the limit specified in RFC 4861,
   the sending router need not include all options in each of these
   Advertisements. 

The citation is made only once in the paragraph, both the protocol name and
the RFC number are clearly associated, and a small bit of repetitive 
verbosity
is reduced.  I'll try to treat the other instances with the same philosophy.
Thanks for pointing them out.

> asking: what about also adding a reference to RFC 4389 (experimental

I don't think that the simple existence of an experimental document that
describes various features of proxy ND agents is a strong argument for
inclusion.  Did you check whether the RFC 4389 specifications are fully
compatible with Mobile IPv6 as currently specified?  I think it would be
wise to do so before making the citation.  If there are cases that are
handled better in RFC 4389 (e.g., ICMP messaging, neighbor cache
operations), then it would be a good idea to (a) make Mobile IPv6
more correct and then (b) cite RFC 4389.  I don't think we can rely
on RFC 4389 to identify the correct behavior, however, because then
the citation would be normative and that would be trouble for an
experimental RFC.

That's a long way of saying I am quite leery of making this citation.
But I'm interested to hear your further comments, and especially if
you have assurance that there are no incompatibilities between
RFC 4389 and rfc3775bis.

> Well, I don't even see how this can work so at the moment, I would

I should have thought more about this before answering the first time.

I agree it isn't clear, because I think there are several scenarios.

First, we can agree that mobile nodes MAY support DHCPv6, right?
The question is how to make it work.  And rfc3775bis might not be the
right place for that.

But here are some (slightly) better considered ideas.

-  the mobile node might use DHCPv6 for configuration information
   other than its IPv6 address
-  the mobile node might use DHCPv6 to extend the lifetime of its
    existing home address
-  the mobile node might try to use its existing home address, but
    get a new address from the DHCPv6 server in reply.
-  for such a new home address, it might need to use IKEv* to
    make a new security association
-  perhaps the old address is still valid for a short time while the
    new IKEv2 packets are tunneled with the home agent
-  the mobile node should be able to run DHCPv6 to get care-of
    addresses to be used on the same network interface as
    is used to support the tunnel to the home agent.

I don't claim that having the abovementioned possibilities makes
the bulleted item in question any more clear, but I'm not sure
how to make it clearer, and I somehow don't think that section
is the right place to lay out all the possibilities for DHCPv6
interactions.

So unless someone tells me different, for now I'll just leave
it alone.

How about:

   In order to do this, when a node begins serving as the home agent it
   MUST have performed Duplicate Address Detection (as specified in
   Section 10.3.1), and subsequently it MUST multicast onto the home
   link a Neighbor Advertisement message [20] on behalf of the mobile
   node.

>>
>>    o  In addition, for all security associations bound to the mobile
>>       node's home address established by IKE, the mobile node MUST
>>       include an ISAKMP Identification Payload [6] in the IKE phase 2
>>       exchange, giving the mobile node's home address as the initiator
>>       of the Security Association [5].
>>

So that I can finish revising rfc3775bis before having to stop and read 
that draft,
can you provide some suggested text for the proposed citation?  I'll try 
to read the
draft in the next few days understand your citation and text.

How about:

   o  Given the availability of the home prefix, the MN checks whether
      or not the home prefix matches one of the prefixes received in the
      RA.  If it does, the MN concludes that it is connected to the home
      link.  Please see Section 15.10 for information regarding the
      security vulnerability associated with this determination.

and,

15.10.  Vulnerabilities from Neighbor Discovery

   The ``Home Link Detection'' mechanism (Section 11.5.2) allows the MN
   to detect when it is at home.  When a MN detects it is at home, it is
   expected to deregister, and also (if in use) to stop IPsec protection
   for data traffic exchanged over the tunnel to its Home Agent.

   Unfortunately, Neighbor Discovery is not a secure protocol.  It is
   possible that some networks may harbor malicious routing agents that
   might advertise false information which would lead a mobile node to
   erroneously determine that it had returned to its home network.

   A draft [40] has been written that discusses the possible threats
   and security impacts associated with the use of this insecure NDP-
   based mechanism as a trigger to drop IPsec protection of data traffic
   for the MN.  It also provides some results on the implementation of
   the attacks against an existing MIPv6 module.  Possible solutions are
   suggested.

And, finally:

> 17.  Acknowledgements
>
>    We would like to thank the members of the Mobile IP and IPng Working
>    Groups for their comments and suggestions on this work.  We would
>    particularly like to thank (in alphabetical order) ...

I wonder if anyone noticed the names had not been in alphabetical order 
:-) for a really long time.

There is still one more issue I am working on before considering this 
revision to be complete.
But I thought it would be better to send this long-ish email out first 
because it will take me a
while to puzzle over that issue.  Plus there are all those citations to 
modify.

Regards,
Charlie P.

---

From: <[email-masked]>
Date: Fri, 9 Oct 2009 23:25:57 +0200

A few comments about some of the citations being proposed:

> draft in the next few days understand your citation and text.

This reference does not add any value to 3775bis. It is more relevant in the
context of 3776 or 4877.  Adding this reference even in the Informative
section is not required.

>    the attacks against an existing MIPv6 module.  Possible solutions are

This is a much larger change to 3775bis. I-D:
draft-ebalard-mext-hld-security-00 has not really been discussed in the MEXT
WG AFAICT and hence making this change based on this reference is not what I
believe is in the scope of the current revision of 3775bis.
If an when the MEXT WG agrees that the threats identified in the referenced
I-D are accepted, it is okay to make these changes.

-Basavaraj

---

From: [email-masked] (Arnaud Ebalard)
Date: Fri, 09 Oct 2009 23:34:20 +0200

> - If another address is available the ULA SHOULD NOT be used.

I think it captures what I had in mind, yes.

Last comment: If the HA uses an ULA, the logic may be a bit different in
some cases (longest prefix match) but if the MIPv6 module supports that
specific case, it will probably implement the right logic I guess. 

Cheers,

a+

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 09 Oct 2009 14:37:59 -0700

Hello folks,

O.K.  I will hold off on submitting the document until this
situation is cleared up.  It is easy for me to omit these new
citations and accompanying text (a lot easier than writing
them in the first place).

Anyway I will put the completed revision on a website
for review before submitting it to the Secretariat.

Regards,
Charlie P.

---

From: [email-masked] (Arnaud Ebalard)
Date: Sat, 10 Oct 2009 00:26:33 +0200

Hi,

<[email-masked]> writes:

> This reference does not add any value to 3775bis.

I'll take that with salt ;-)

> It is more relevant in the context of 3776 or 4877.  Adding this
> reference even in the Informative section is not required.

I think rfc3775bis is about correcting issues and clarifying parts of
3775 based on existing feedback. IMHO, this is exactly what this
informational reference provides.

Even if you are against the use of IPsec/IKE with MIPv6, this is the
security mechanism used by the protocol. And providing informational
pointers in the spec to possible solutions to support

 - correct use of IKE with MIPv6
 - efficient use of IPsec for protection of tunneled data

is useful. It's not fair to keep saying that MIPv6 does not work with
IPsec/IKE and in the meantime prevent efforts to clarify the
interactions between the protocols to be added to the specs.

That been said, I think I have argued enough on that aspect. I'll let
Charles capture the thoughts of the working group and decide what to do.

> WG AFAICT

True. I think I only got a comment from Julien.

> and hence making this change based on this reference is not what I

Fine with me.

Cheers,

a+

---

From: [email-masked] (Arnaud Ebalard)
Date: Sat, 10 Oct 2009 00:41:53 +0200

Hi Charles,

fine with me.

> improvements I can unilaterally decide to do.

I agree with you. I would understand if this is kept as is for that reason.

> verbosity is reduced.

looks ok.

> I'll try to treat the other instances with the same philosophy. Thanks
> for pointing them out.

Thanks

> you have assurance that there are no incompatibilities between

ok. Let's just drop that comment then. I don't think this is worth
losing our time on that.

> First, we can agree that mobile nodes MAY support DHCPv6, right?

yes, it might.

> The question is how to make it work.  And rfc3775bis might not be the

I agree. There are some thoughts on the topic in 10.4.4 but I don't
think this would help a lot.

ok.

> So that I can finish revising rfc3775bis before having to stop and
> read that draft,
> can you provide some suggested text for the proposed citation?  I'll
> try to read the

Considering Basavaraj's comments and unless other people in the WG
supports the inclusion, this introduction to the content of the draft is
more for you to understand what it discusses if you decide to read it:

MIPv6 requires the use of IPsec for protection of signaling
traffic. Static keying must be supported. Dynamic keying (using IKE) is
optional. Traffic tunneled between the MN and its HA may optionnally be
IPsec protected. 

When a handovers occurs, the CoA changes. For IKE this basically implies
that the IKE_SA (Phase 1 for IKEv1) is no more usable. Additionally,
when tunnel mode is used, the states maintained by the IKE daemon
(mirrored SP and SA endpoints information) are wrong (they reference the
wrong address). The endpoint of the tunnel mode SA present in the IPsec
stack are also wrong for the same reason after the handover.

The draft provides *a* solution to support the update of previous
elements, and prevent the need to drop and rekey everything (and/or
force the user to manually update its SP/SA).

Implementations of the mechanism are publicly available (Linux Kernel,
racoon IKEv1 daemon, StrongSwan IKEv2 daemon and UMIP MIPv6 daemon).

>   the attacks against an existing MIPv6 module.  Possible solutions are

Works for me. But let's let the WG decide if this fits.

> I wonder if anyone noticed the names had not been in alphabetical
> order :-) for a really long time.
>
> while to puzzle over that issue.  Plus there are all those citations
> to modify.

Thanks for your work,

Cheers,

a+

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 09 Oct 2009 15:47:53 -0700

> Charles capture the thoughts of the working group and decide what to do.

Well, if I have to -- but more better would be to have the working
group establish the resolution with consensus gauged by the WG chairs.
I'm in the mode of avoiding controversy on these points :-)

Regards,
Charlie P.

---

From: <[email-masked]>
Date: Sat, 10 Oct 2009 00:48:26 +0200

Inline:

> I'll take that with salt ;-)

Only if you disagree about my comment. 3775 does not discuss the security
details and hence mentioning Pfkey interface here has no value.

> informational reference provides.

Agree about what the intent of 377bis is. However the reference that you are
suggesting should be a part of the IPsec/IKE(v2) RFCs because it makes more
sense there.  

> security mechanism used by the protocol.

I am not "against" the use of IPsec/IKE with MIP6. I just think that it is
an impractical security model for MIP6.

> And providing informational

Right. But not in the context of 3775bis. The aspects of security are
specified in other RFCs which would be the relevant place to provide the
reference. 

> interactions between the protocols to be added to the specs.

FWIW we do have a working implementation of MIP6 with IPsec/IKEv2. So I have
never stated that it does not work. I am of the opinion that there are
better security approaches that are easier to implement and deploy for MIP6.
IPsec/IKEv2 was the wrong choice for MIP6 security. However just because
that is what has been specified does not mean we cannot improve it. It is in
the WG and IETFs interest to specify a protocol that is actually
implementable and used rather than defining something which would challenge
implementers without any real benefit.

> Charles capture the thoughts of the working group and decide what to do.

Sure.

-Raj

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 9 Oct 2009 15:56:53 -0700

Basavaraj,

Basavaraj Patil wrote: 
> read
> try

Speaking as an individual regarding whether or not addition of the reference is required: Well, informative references are by definition informative and are not required to be read to implement the specification. IMHO the reference does provide useful information since it points to an API between IPsec and MIPv6 which is implicitly assumed in the design of 3775.

That being said, I agree with you that such a reference would also be relevant in the context of 3776 and 4877.

--julien