On Wed, 24 Mar 2010 17:47:09 -0500
"Hemant Singh (shemant)" <shem...@cisco.com> wrote:
> Hey folks,
>
>
>
> It's not that an IPv6 home router has one WAN interface acting as a
> router while another interface on the home router is a host. The
> problem is also not about a home router or a router sitting in the
> Internet core or the WAN. Any router has one or more network
> interfaces over which the router performs routing. But when the
> network interface is acquiring an IPv6 address, it is then the interface
> is acting as a host. Sorry, I didn't read the
> draft-kohno-ipv6-prefixlen-p2p-01.txt yet but the concept seems fine to
> me to use a /127. We may have to make sure the language in the document
> is tight because IPv6 has so many restrictions like a /64 prefix length
> for SLAAC addresses and the like.
>
I have read it, and unfortunately I don't think it provides any
compelling arguments for /127s at all.
I'll state up front that I'm in the /64 camp for everything, because I
like the simplicity of it, with simpler usually meaning cheaper to
operate and less prone to error. I am willing to be convinced that
other prefix lengths should be supported, however it'll need to either
be significantly cheaper than the value in simplicity of
universal /64s, or something that can't be done equivalently with /64s.
I haven't found anything that meets either of those criteria.
"4. Problems identified with 127-bit prefix lengths in the past
[RFC3627] discourages the use of 127-bit prefix lengths due to
conflicts with the Subnet-Router anycast addresses. However, the RFC
also states that the utility of Subnet-Router Anycast for
point-to-Problems identified with 127-bit prefix lengths in the past"
This section does not fully summarise the all the arguments for
avoiding /127s in RFC3627. RFC3627 makes two arguments - specifically
against /127s, as well as against using any prefix lengths longer
than /64s e.g.
"5. Other Problems with Long Prefixes
These issues are not specific to /127.
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."
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.
"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?
"5.2. Neighbor Cache Exhaustion issue
As described in Section 4.3.2 of [RFC3756], the use of a 64-bit
prefix length on an inter-router link that uses Neighbor Discovery
(e.g., Ethernet) potentially allows for denial-of-service attacks on
the routers on the link.
Consider an Ethernet link between two routers A and B to which a /64
subnet has been assigned. A packet sent to any address on the /64
(except the addresses of A and B) will cause the router attempting to
forward it to create an new cache entry in state INCOMPLETE, send a
Neighbor Solicitation message to be sent on the link, start a
retransmit timer, and so on [RFC4861]."
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. I think LAN segments might
be a more entertaining target for this DoS attack - not only do you
clog up the router's ND cache with unresolved entries, you also create
large amounts of multicast NS traffic on the attached LAN, possibly
flooded out all downstream switch ports, and creating processing load on
downstream PCs who's addresses match solicited node multicast addresses.
That is an argument for supporting longer than /64s on LAN segments
too. However then we loose the advantage of using EUI64s as IIDs, other
useful mechanisms like CGAs, SLAAC etc.
I think this problem needs to be fixed in Neighbor Discovery.
One possible way would be to make Neighbor Discovery
stateless by using the flow label field in a NS/NA transaction carry a
transaction cookie, such that the router can verify it issued the
trigger NS without having to remember any state for it while it is
outstanding.
"5.3. Other reasons
1. With the use of 127-bit or other long prefix lengths, interface
IDs are simpler and easier to remember (e.g., the Interface ID is
0 or 1)."
::1/64 and ::2/64 are just as simple (arguably even more so - most
people don't start counting at 0), plus you don't have to remember that
you've got at least two different prefix lengths on your network.
You're also not going to have to worry about the values of the 70th and
71st bits, as they'll be set correctly. In my opinion, that
makes ::1/64 and ::2/64 significantly simpler than ::0/127 and ::1/127.
"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. It also protects against somebody attaching to the link
and spoofing one of the legitimate routers' source addresses, and
sending a bogus routing update. If there is a flaw in a router allowing
to send a spoofed offlink routing update, authentication protects
against that too.
"3. Though address space conservation considerations are less
important for IPv6 than they are in IPv4, it may still be
desirable to use the smallest possible prefix to number links
(and thus use, for example, /127 for point-to-point links). For
example, a large end-site that is assigned a /48 of IPv6 space
may not want to reserve a full /64 for every point-to-point link
to avoid renumbering in the future."
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), you make your life harder by choosing
different prefix lengths, remembering to manage the 70/71 bit
issue, saving 16 383 /64s for your up to 65 535 LAN segments (of which
you'll never ever be likely to have)? If you are one of the rare
organisations who will have a network that large, you'll be getting
bigger than a /48 anyway. I don't think renumbering due to a lack of
address space needs to be much of a consideration in IPv6 addressing.
As I said at the outset, I'm willing to be convinced that there are
reasons to have longer than /64s. I just don't find any of the above
arguments compelling.
Regards,
Mark.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
