On Thu, Mar 25, 2010 at 2:53 AM, Mark Smith < i...@69706e6720323030352d30312d31340a.nosense.org> wrote: > > One should note that [ADDRARCH] specifies universal/local bits (u/g), > which are the 70th and 71st bits in any address from non-000/3 range. > When assigning prefixes longer than 64 bits, these should be taken > into consideration; in almost every case, u should be 0, as the last > 64 bits of a long prefix is very rarely unique. 'G' is still > unspecified, but defaults to zero. Thus, all prefixes with u or g=1 > should be avoided." >
Is it enough to say in the draft that the u/g bit should be set to zero when the operator assigns /127 prefixes? > If the purpose of the draft-kohno-ipv6-prefixlen-p2p-01.txt draft is to > contradict the position of RFC3627, then I think the draft needs to > address all the points made in RFC3627, not just the Anycast > router one. That would fundamentally mean changing the updated > version of RFC3513, RFC4291, "IP Version 6 Addressing Architecture" to > support interface identifiers that are smaller than 64 bits. > That's why the draft updates RFC 4291. Is this not sufficient? "5.1. Ping-pong issue > > As described in [PINGPONG], a forwarding loop may occur on a point- > to-point link with a prefix length shorter than 127. This does not > affect interfaces that perform Neighbor Discovery, but some point-to- > point links, such as SONET, do not use Neighbor Discovery. As a > consequence, configuring any prefix length other than 127 bits on > these links creates an attack vector in the network." > > I'd like to understand why SONET links don't use ND. Are there any > references to operating IPv6 over SONET that explain why ND can't be > enabled? > I don't know. It's possibly just not implemented because in general it's not very useful to do neighbor discovery on a link that can only have one other host on it. Maz, can you comment here? There is no denying this is an issue. However, it is not unique to > point-to-point links - a router attached to an edge /64 LAN segment with > downstream PCs is just as vulnerable. Proportionally, there are > usually at least equal and commonly far more LAN segments in most > networks than there are point-to-point links. Adopting /127s for > point-to-points will mitigate this problem for them, however you're > still vulnerable for all your LAN segments. Correct. However, as the draft says, the operational impact of taking out a large (e.g., 80 Gbps aggregate) backbone link or inter-operator peering link using something like this is vastly superior to the impact of a DoS attack on one LAN, which typically has lower-speed links. "2. Using 64-bit prefixes for inter-router links leaves a large > number of unused addresses that an attacker with physical access > to a link could use to insert a node onto the link without having > to compromise the routing protocols used on the link. If 127-bit > prefix lengths are in use, this is not possible." > > People are enabling authentication in routing protocols to protect > against this. No - as the draft says, you cannot protect against this by enabling authentication in routing protocols. If you assign a /64 to a link and someone inserts host(s) onto the link, the hosts will be able to send and receive packets regardless of routing protocol authentication, since the routers are already configured to route the whole /64 to the link. Doing this on a /127 link will require taking the address belonging to one of the two routers (e.g., by triggering DAD, or MAC address spoofing) which will immediately be visible to the operator > So you've got your /48, with 65 536 subnets, and instead of allocating 16 384 /64s for point-to-points links (of which you'll never be ever > likely to have), leaving 49 152 /64s for LAN segments (of which you'll > never be every likely to have), Really? It seems to me that depending on how you design your network, you might have as many as one or two point-to-point links for each LAN, because you need to number the uplinks of the routers that provide service to the LANs. So you'd end up dedicating 50% or 66% of your address space to P2P links. Seems like a waste to me, and if the argument is "640k should be enough for everybody", well... we know how it went with IPv4. Cheers, Lorenzo
-------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
