Subject: IPDir Review of draft-ietf-l2vpn-arp-mediation-09.txt

From: Margaret Wasserman <[email-masked]>
Date: Fri, 21 Mar 2008 16:55:26 -0400

NOTE:  I am not on the L2VPN mailing list, so please include me  
explicitly on any discussion.

Hi L2VPN Folks,

At Mark Townsley's request, I performed an IP Directorate review of  
draft-ietf-l2vpn-arp-mediation-09.txt, paying special attention to  
the IPv6 portions of the document.

I found three fairly major IPv6-related issues with the document:

(1) This document makes the incorrect assumption an IPv6 host (non- 
router) will only have a single IP address associated with an  
interface.  Virtually all IPv6 nodes will have more than one address  
per interface, and the mechanisms described in this document are  
incompatible with that fact in multiple ways:

- If there is more than one IPv6 address in the IP Address List TLV,  
it is assumed that the first address is the address of the CE and the  
other addresses are "on-link addresses".
- It is assumed that an Inverse Neighbor Discovery Advertisement will  
only contain a single address, when
it actually contains an address list.
- The PE operates on the assumption that there is a single CE with a  
single IP address, so once it discovers a single address during the  
"monitoring state", it communicates that address to the remote PE and  
thinks that discovery is complete.  However, this is not valid for an  
IPv6 node that may have more than one address on the interface and  
may configure new addresses on that interface (such as IPv6 Privacy  
Addresses) at any time.

(2) The document reflects a misunderstanding of the contents of an  
IPv6 Router Advertisement message, referring to "on-link addresses"  
while the Router Advertisement actually contains on-link prefixes.   
This misunderstanding is reflected in the format of the Address List  
TLV which does not include prefix lengths for the on-link prefixes.

(3) I'd like to see some explanation of how this mechanism interacts  
with Duplicate Address Detection (DAD).  I believe that DAD will only  
function on the AC and not across the PW.  Will the PE-to-PE  
communication include a check that no address duplication has  
occurred? If not, is there a reason to believe that DAD isn't needed?

I also had concerns or questions about several other portions of the  
document:

(4)  The document says:

      "The establishment of the PW occurs independently from local CE
      IP address discovery. During the period when the PW has been
      established but the local CE IP device has not been discovered,
      only broadcast/multicast IP frames are propagated between the
      Attachment Circuit and pseudowire; unicast IP datagrams are
      dropped. The IP destination address is used to classify
      unicast/multicast packets."

Why are unicast packets dropped during this phase?  What are the  
implications of dropping these packets if, for example, the CE device  
is attempting to perform DHCP?

(5)  The document also says:

      "The unicast IP frames are propagated between AC and pseudowire
      only when CE IP devices on both Attachment Circuits have been
      discovered, notified and proxy functions have completed."

How will both sides know when the other side has completed these  
functions?

(6)  In section 5.1.4, the document says:

         "o  The PE learns the IP address of the local CE from the
            Configure-Request received with the IP-Address option
            (0x03). The PE verifies that the IP address present in the
            IP-Address option is non-zero. If the IP address is zero,
            PE responds with Configure-Reject (as this is a request
            from CE to assign it an IP address). Also, the Configure-
            Reject copies the IP-Address option with a zero value to
            instruct the CE to not include that option in new
            Configure-Request. If the IP address is non-zero, PE
            responds with Configure-Ack."

It also says:

      "The IPCP IP-Address option MAY be negotiated between the PE and
      the local CE device."

This does not seem to be internally consistent.  Up above, the  
document seems to indicate that the PE will reject a configure  
request with an IP address of zero (indicating a request to provide  
one) and in this paragraph it indicates that the IP-Address option  
may be "negotiated".  What does this mean?

(7) In section 5.1.5, the document says:

      In order to learn the IP address of the CE device for a given
      Attachment Circuit, the PE device may execute Router Discovery
      Protocol [RFC 1256] whereby a Router Discovery Request (ICMP -
      router solicitation) message is sent using a source IP address
      of zero.

Why is the router discovery packet sent with a source address of zero?

(8) How would this mechanism interact with Secure Neighbor Discovery  
(SEND)?  This issue should be covered in the security considerations  
section, IMO.

I also found a few borderline-editorial issues that, IMO, merited a  
mention:

(9) There is no reference for Inverse ND.  You need to add RFC 3122  
as a normative reference and refer to it in the appropriate location.

(10) The document says:

      "Address Family
           Two octet quantity containing a value from the ADDRESS
           FAMILY NUMBERS from ADDRESS FAMILY NUMBERS in [RFC 3232]
           that encodes the address contained in the Address field."

There must be an IANA registry for this that it would be better to  
use than RFC 3232.

(11) The reference to RFC 1256: ICMP Router Discovery Messages,  
should be normative not informative.

(12) There are numerous "nits" in the document -- references in the  
abstract, acronyms that aren't expanded at first use, etc.  You  
should address these in the next update.

Margaret