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

["Charles E. Perkins" <[e-mail]>]

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.