Brian and authors, My response below. Thus I cannot support this going to the IESG without further discussion as my input. I also support Margaret's request for this to be checked by RTSP persons, and I realize Dave T. clearly has this expertise but it is a good logic check. Unless we want to remove RSTP. I think we should include RSTP but it needs more review.
General Comments: I also would like to see this work not focus at all on IPv4 and only address IPv6. The IPv4 work should be a separate document completely. To permit this behavior for prefixes to span links in IPv6 is a significant change to one of our architectural precepts for IPv6 and cannot be considered lightly, regarding link behavior. Because it is an informational document I do not ask for implementation but it would be good to suggest this somewhere in the spec. If it were going to PS then implementation in this case is example where I think the IETF has to ask for that as it could negatively impact current and future deployment of IPv6. I would like to see a third scenario that aligns better with section 4. The two presented are ok but depicting two links with proxy between as in section 4 would be good scenario to add. I think DHCPv6 needs to be addressed when in use by the client and is missing in the discussion. Specific comments below: From >3.1. Non-requirements >The following items are not considered requirements, as they are >not met by classic bridges: > The following additional items are not considered requirements for > this document: >o Support Neighbor Discovery, Router Discovery, or DHCPv4 > packets using IPsec. We also note that the current methods > for securing these protocols do not use IPsec so this is > considered acceptable. That IPsec will not be used or is not being used for ND is simply not valid or true. This may be an opinion or state for deployment by the authors but it is certainly not the view of all regarding deployment. Thus IPsec must be addressed if it is used and a statement what this means to the ndproxy proposal. I feel this is a hard requirement. This shows up again below as issue for me indirectly. From >4. Bridge-Like Proxy Behavior >As with all other interfaces, IPv4 and IPv6 maintain a neighbor >cache (aka "ARP cache") for each proxy interface, which will be >used as described below. For readability, we will describe the >neighbor cache as if both IPv4 and IPv6 neighbors use the same >state machine described in [ND]. That is not good to state IPv4 can use same abstraction as ND and gives the wrong impression to a reader. It simply is not true for most implementations. But, I would like IPv4 removed from this spec. The ND spec clearly documents the diffs and they are great enough to even compare or identify in this manner is not prudent in a specification. >4.1.3.3. DHCPv4 Packets Need section on DHCPv6. >4.1.4.3. ICMPv6 Router Advertisements >If an RA with the P bit set has arrived on a given interface >(including the upstream interface) within the last 60 minutes, >that interface MUST NOT be used as a proxy interface; i.e., proxy >functionality is disabled on that interface. The Proxy is acting as a router and this requirement for a P bit does affect router implementations and that was a non goal. This is a discrepancy and if the Proxy is a router it needs to adhere to that which a router must do and that needs to be added to the spec somewhere. >4.2. Originating Packets >P receives the solicitation (since it is receiving all link-layer >multicast packets) and processes it as it would any multicast >packet by forwarding it out to other segments on the link. >However, before actually sending the packet, it determines if the >packet being sent is one which requires proxying. Since it is an >NS, it creates a neighbor entry for A on interface 1 and records >its link-layer address. It also creates a neighbor entry for B >(on an arbitrary proxy interface) in the INCOMPLETE state. Since >the packet is multicast, P then needs to proxy the NS out all >other proxy interfaces on the subnet. Before sending the packet >out interface 2, it replaces the link-layer address in the SLLA >option with its own link-layer address, p2. This a routing function though a proxy and do we want to add this function to router requirements. This also has security issues that could cause DOS and affect data integrity of the network configuration parameters. >6. Loop Prevention >Loop prevention using RSTP would typically be done by devices that >already implement this protocol as a result of supporting normal >briding functionality, and is done here as follows. IEEE 802 >interfaces use the protocol exactly as specified in [BRIDGE]. >Operation of RSTP over other types of link layers is done by >encapsulating the RSTP frame in an IPv6 header. The Next Header >field is set to [TBA by IANA], indicating that an RSTP header >follows. The Destination Address field is set to the Link-scoped >RSTP Multicast Group [TBA by IANA]. All proxies operating on non- >IEEE 802 media join this group so they will receive RSTP packets. >RSTP packets are never forwarded or proxied. Now packets are being added for NH and DST options and that needs to be checked if it is the best method to perform this function. It might be better as hop-by-hop option rather than DST option as thought. This should all be checked with RTSP WG in IETF. >Loop avoidance using the P bit in RAs is done as follows. The >proxy determines an "upstream" proxy interface, typically through >a physical choice dictated by the scenario (see Scenarios 1 and 2 >above), or through manual configuration. As described in Section >4.1.3.3, only the upstream interface is allowed to receive RAs, >and never from other proxies. Proxy functionality is disabled on >an interface otherwise. Finally, a proxy MUST wait until it has >sent two P bit RAs on a given "downstream" interface before it >enables forwarding on that interface. We have now used up precious bit space in ND and I do not see the justification unless we open this concept to working with general router implementations and that is what the proxy is in my view. >7. Guidelines to proxy developers This should be appendix not part of the specification. It is conjecture and suggestion that is all. >9. Security Considerations The security section is fair assessment but assuming SEND is not valid and many of us have many issues with SEND including but not limited to IPR, interface with PKIs, and that it does not assist with identification of the node on a wireless network. NDproxy now permits a rogue node to not only attack one link but now multiple links via the Proxy and thus exacerbates the entire problem we have with stateless wireless nodes in general. This needs to be added to the current list of security section. In addition I would like to see a softer support that SEND solves anything and a TBD. thanks /jim > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Brian Haberman > Sent: Tuesday, May 24, 2005 7:40 AM > To: IPv6 WG > Cc: Bob Hinden > Subject: IPv6 WG Last Call:draft-ietf-ipv6-ndproxy-02.txt > > IPv6 WG, > This begins a 1-week Working Group Last Call on advancing: > > Title : Bridge-like Neighbor Discovery > Proxies (ND Proxy) > Author(s) : D. Thaler, et al. > Filename : draft-ietf-ipv6-ndproxy-02.txt > Pages : 20 > Date : 2005-5-23 > > as an Informational document. Substantive comments should be > directed to the mailing list. Minor comments and editorial issues can > be sent to the editor. This last call will end on June 3, 2005. > > We also request that people comment on their support or opposition > to advancing this document. There has been mixed public support for > this work and it cannot advance without consensus from the working > group. > > Regards, > Brian & Bob > IPv6 WG co-chairs > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
