Hi Lorenzo, On Thu, 25 Mar 2010 12:00:58 -0700 Lorenzo Colitti <[email protected]> wrote:
> On Thu, Mar 25, 2010 at 2:53 AM, Mark Smith < > [email protected]> 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 it was "must set", it would be. > > > 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? > I don't see anywhere it specifically says RFC4291 is to be updated, or replacement text for the impacted section(s). > "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. > The thing is, these types of attacks aren't going to stop even if you protect your p2p links using this method. There would still be many vulnerable parts, which could also be hosting content just as important as your 80Gbps backbone link. Imagine high profile content provider sharing a /64 across a cluster of hosts acting as a front end for a search engine. > "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 > Well then I think this is an unauthorised link layer access problem. Your LAN segments are far more vulnerable - there are points of attachment to them at every staff member's desk. point to point links between routers are typically in physically secured infrastructure or facilities. If you're still worried about those point to point links being vulnerable to this attack, then you're probably willing to put up with the overheads of enabling IPsec or if it's available, linksec. > > > 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. > You're right, "it depends". The draft doesn't say this advice depends on the network scenario and design. My example is of what I think will be the common case. Most corporate networks, the most common large networks, have ratios of more LANs to WANs/point-to-point links. As this section isn't specific about scenarios, I think it is making a general recommendation that applies to the most common cases, and I disagree with it as a general recommendation because you're unnecessarily saving a lot of what you have an "excess" off, at the cost of simplicity. >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. > Waste is something you get nothing for. If you use address space to get simplicity and operational convenience, you're not wasting addresses. We love the simplicity and convenience of Ethernet addresses because they're plug-and-play, and they can be because they're larger than they operationally need to be. The 640K thing is an interesting one. IIRC (from some history books, I'm not quite old enough to have known these details) the very first IBM PC had 16KB of RAM. The 8086 had a maximum memory size of 1MB. The ROM BIOS in the PC was so limited that IBM knew that add-in devices would be adding in BIOS code, so they reserved a relatively large amount of address space out of that 1MB, leaving 640K for RAM. Reserving 640KB when you're shipping with 16KB? That statement, "640k should be enough for everybody", starts to sound quite reasonable in that context. IPv4 was the same I think. If you dig into the pre-RFC791 versions of the IP protocol e.g. RFC760 and earlier IENs, they only allowed a single network octet i.e. all addressing was "class A". So for quite a number of years, there was an expectation of no more than 256 networks in the Internet. I think both of these are examples of completely unexpected and wild success. I think in IPv6 that has been learned from, which is why the default allocation of a /48 of subnets is so "large" - they want to make sure address space is something that isn't a constraint for most people to increase the size of their network. Regards, Mark. -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
