Hi, I've read through this update to the draft, and have a few questions / comments.
o Ethernet point-to-point links " This may include Ethernet links which are configured to be point-to- point. In such cases, there is no need to support Neighbor Discovery for address resolution, and other general scenarios like the use of stateless addresss autoconfiguration are not relevant." If the second sentence applies to the Ethernet scenario, then how do the routers on each of this link know what destination MAC address to put in the Ethernet frames? It would seem to me that there are at least three possible options: - static configuration of destination MAC addresses Impractical IMHO for the operational overhead it creates (error prone including typos, breaks if interface module is changed etc., chances of these errors go up if the changes are occurring in the early hours of the morning) - Enabling ND NS/NA for destination MAC address discovery with a /127 prefix length, the neighbor cache exhaustion attack has been mitigated, so I don't think there is any harm in having ND NS/NA occur on these links. It also allows ICMP Destination Unreachables to be generated if the remote IPv6 address becomes unavailable - Switch off link layer address recognition on the Ethernet interfaces a.k.a. "promiscuous mode". This would make the Ethernet link a true layer 2 point-to-point link. A neat trick might be to re-purpose the address fields in the Ethernet headers to carry different information e.g. MPLS label stack, similar to how DLCIs were re-purposed in MPLS over frame relay. o Link local addressing Are link local addresses required on this link? How is it generated, and what is its prefix length? o Generating ICMP Destination Unreachables As mentioned earlier, one of the consequences of using a /127 is that the ND neighbor cache is now not vulnerable to exhaustion DoS attacks, because the address space assigned to the link is so small. Wouldn't it be better to switch NS/NA/NUD back on for these links (i.e. all p2p, not just Ethernet), so that they can now generate ICMP Destination Unreachables, which is a MUST according to RFC4861? o Applicability to customer PPP p2p links How can /127s be applied to customer PPP/PPPoE point-to-point links. They're just as vulnerable to the issues this draft is addressing, and as there's likely going to be many magnitudes more of them compared to SONET/SDH/Ethernet point-to-point links between routers upstream of the network edge, they'll also possibly be a large target for attackers. As an example, I'm working on a scenario where there are probably no more than 200 to 300 inter-router point-to-point links upstream of the network edge, but there are over 150K+ PPP sessions attaching customers to that network. Being able to protect those 150K+ PPP sessions from these issues would be very valuable. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
