ndproxy-00 (General comments)

["Chirayu Patel" <chirayu@xxxxxxxxxxx>]

Hello,

Few comments on draft-thaler-ipv6-ndproxy-00.txt.

CP


1. Section 1. First bullet following the first paragraph.

   The first bullet talks about an "access point". Give a reference to
   the 802.11 spec. Should 802.11 be mentioned in the first place? What
   advantage does ndproxy provide over classical bridges in an
   802.11 network?

2. Section 1. 2nd Paragraph. 

   Rephrase to:

   It is expected that whenever possible links will be bridged at the
   link layer using classic bridge technology.

   Bridging at the network layer SHOULD be used only when the classic
   bridges cannot be used. For bridging at the network layer, a single
   "bridge" interface will be exposed to the IP layer. In the
   remainder....

3. Remove the reference to MLSR, the document is no longer present in
   the I-D directory.

4. Section 1.

   The explanation about the simple RA proxy is unclear. The terms
   "downstream link" and "upstream link" are unclear. I started of with
   the assumption that the upstream link refers to the bridge segment to
   which the router is connected, and the downstream link is another
   segment to which the RA's are to be forwarded. But then I could not
   understand the problems caused. This approach needs some elaboration.

   Appendix section seem to be the correct place holder for alternate
   approaches. In other parts of the document, they distract the
   reader.

5. Section 1.1.

   Remove the line -> "It should appear as if one host uses multiple
   addresses." It does not seem to add anything more that what is
   specified in the previous sentence. In addition, it is semantically
   incorrect. The router will never see the bridged hosts, as one
   single host with multiple addresses.

6. Section 1.1

   Remove the sentence starting with "If, on the other hand, neighbor
   ...". This sentence refers to implementation, and it is too early
   in the document to do so.

7. Section 1.1

   Add the following requirements.

   a) Allow dynamic addition/removal of proxies, and nodes to the
      network without disrupting traffic.

   b) The proxy should be able to interwork with a 802.1d compliant
      bridge.

8. Section 1.2

   Rephrase the first requirement to

   "Should not require assignment of an IP address. It implies that the
   bridge will not be visible in traceroute scans."

9. Section 1.2 4th bullet.

   Rephrase to:

   Transparently support different MTU's in use on different segments.
    
   The rest of the text should be moved in another section.

   <Please refer to the other mail on suggested text>

10. Section 2. 4th Paragraph

    The IPv4, and IPv6 implementation in the proxy is not going to
    complete. I also can't think of the usage of the various neighbor
    cache states in the proxy, and moreover, it cannot be implemented
    as is.

    <In my other email, I propose a simplified neighbor cache that can
    be implemented in the proxy.>

11. Section 2. 5th Paragraph

    What about processing of DHCPv6 packets? Don't they carry hardware
    (link-layer) addresses?

    Thinking a bit more about "packets that will need address
    substitution" issue - providing a set of guidelines will help
    implementors in deciding whether the link-layer address in the
    payload of a protocol should be substituted by the link-layer
    address of the proxy will help.

    Such guidelines will also take care of future protocols, and this
    document will not have to be updated.

    My view of the guidelines is:

    1. If the link-layer address in the payload of the protocol can be
       used in the link-layer header of future messages, then the
       proxy should substitute it with its own address. For example
       the link-layer address in NA messages is used in the link-layer
       header for future messages, and, hence, the proxy substitutes
       it with its own address.

       For broadcast/multicast packet the link-layer substituted
       within the payload will be different for each outgoing port.

    2. If the link-layer address in the payload of the protocol is
       never used in the link-layer header, then the proxy should not
       substitute it with its own address. In this case, the
       link-layer address maybe included in the protocol payload to
       uniquely identify the node. For example, link-layer address in
       DHCPv4 messages is not substituted by the proxy, as that address
       is never used in the link-layer header of any future messages.

    3. All messages with unspecified IPv6/IPv4 destination address
       should be broadcast on all ports.

15. Section 2. 13th paragraph.

    Following the above guidelines will not require modification of
    the BROADCAST flag in the proxied DHCPv4 packet. (I might be
    mistaken, I have yet to confirm this with the DHCP specs)

16. Section 2. 8th paragraph.

    Maintaining the same states in the neighbor cache as those in a
    node is not correct. The proxy will not implement the node
    procedures, and will not do state transitions in the same
    manner. IMHO, more light needs to be shed on the subject. <I have
    proposed a state transition table for proxies in my other email>

    I also propose adding the following text : If a unicast message is
    received for a destination for which there is no entry in the
    neighbor cache then the message has to be forwarded on all
    segments.

17. Section 2. 10th paragraph

    Issues that may be encountered during address substitution should
    be mentioned. They might seem obvious, but a mention will help the
    developers.

    One issue that I can think of is :

    1. The link layer address will be new, and might have different
       length. The new link layer address will result in
       re-computation of certain parts of the IPv4/IPv6 header.

18. The proxy peeks inside certain messages, and replaces the
    link-layer address with the link-layer address of the proxy. It is
    not clear however the link-layer address of which port is
    chosen. It seems that it will be the link-layer of the outgoing
    port. This one needs some clarification.

18. Section 2. 6th paragraph

    This paragraph defines the working of the proxy when "any other"
    broadcast or multicast packet is received. It is mentioned that
    the packet "is forwarded unchanged out all other proxy interface
    on the same link".

    Text needs to be added about how the message the packet is
    forwarded on interfaces on other links.

19. Section 2. 12th Paragraph
    
    What is the advantage of clearing the Override bit?

Some of the comments might not be relevant if the document is
reorganized.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------