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 [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------