On Fri, 26 Mar 2010 10:25:42 +1300 Brian E Carpenter <brian.e.carpen...@gmail.com> wrote:
> On 2010-03-26 08:00, Lorenzo Colitti wrote: > > 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? > > s/should/MUST/. And IMHO that alone is sufficient reason to progress > this draft. Operators already use /127 prefixes for router/router links, > they will continue to do so whatever the IETF writes, but they would > likely respect this rule if it was documented. > > Yes, this is an exception to the general rule, but if point-to-point > links between routers aren't a special case, I don't know what is. > > I don't think we need to justify obsoleting an informational > RFC in the face of reality. Just make this a short BCP, with > most of the words removed. > > Alternatively, we could continue to ignore the real world. > Well, I live in that operator world too. Just because things have been done in the past incorrectly doesn't justify making it acceptable. They can be considered as "IPv4 thinking" aberrations. > Brian > > > > > >> 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 > > -------------------------------------------------------------------- -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
