Fw: IPv6 network policies

[Mark Smith]

Well I took this off-list as Ole requested two weeks ago. As I spent at
least 45 minutes on it, and haven't got any response, I thought I'd
send it through to the list, so that I'll at least get some value from
the time I spent on it. Hopefully it is of some use to others. I think
it very clearly justifies why P2P links should have NS/NAs performed -
to test address assignment and availability.


Begin forwarded message:

Date: Mon, 12 Apr 2010 21:49:04 +0930
From: Mark Smith
<nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org> To: Ole
Troan <otroan at employees.org> Subject: Re: IPv6 network policies


Hi Ole,


On Mon, 12 Apr 2010 09:21:30 +0200
Ole Troan <otroan at employees.org> wrote:

> Mark,
> 
> >>> It's well known that the pong pong problem doesn't exist if ND
> >>> NS/NAs are used.
> >> 
> >> I presume by saying "NS/NA", you mean the address resolution function of ND.
> >> see section 7.2:
> >> 
> >>   "Address resolution is the process through which a node determines the
> >>   link-layer address of a neighbor given only its IP address.  Address
> >>   resolution is performed only on addresses that are determined to be
> >>   on-link and for which the sender does not know the corresponding
> >>   link-layer address (see Section 5.2).  Address resolution is never
> >>   performed on multicast addresses."
> >> 
> >> in particular see "does not know the corresponding link-layer address".
> >> 
> > 
> > I don't agree, because I would consider knowing a link layer address
> > doesn't exist (verified by the absence of a NA in response to an NS) as
> > significantly different from assuming it exists, which is your
> > position. The latter position is what is causing the ping-pong problem.
> 
> where do you get the idea that there are any assumptions made?
> the link has no link-layer addresses. there is nothing to resolve. you don't need to send an NS to figure that out, it is a property of the link type.
> 
> I don't think we'll get much further in this discussion, so lets end it here or take it off-list.
> 

Ok.

For get for the moment that we're talking about P2P links (and
specifically IPv6)

What is the purpose of the prefix length when assigning a subnet to an
interface? As protocols like IPv6, IPv4, IPX and Appletalk don't track
individual end-node addresses, unlike CLNS, the prefix length is an
indication of the range addresses that _may_ be present on the link.
Some of those addresses may be assigned to devices, others may not. And
even then, there is no guarantee that the device will be available when
you wish to communicate with it. It could be there when the packet
leaves the router's interface, yet while the packet is in flight, the
device disappears. IOW, you only know if a packet is going to
arrive after it has.

This is of course why packet networks are called unreliable/best effort.

One of the best ways I've heard to describe this idea is that when a
protocol doesn't track end-nodes individually, then routing information
is really only a 'hint' - because the routing information summarises
information, therefore you are only getting an indication of what
might be there, not what is there. Because you summarise information,
you lose accuracy. Even then, for protocols that do track end nodes it
still is a hint, not a status, because of the target failure during
flight scenario.

(I think I first read of this hint description in -
"48-bit Absolute Internet and Ethernet Host Numbers"
- http://ethernethistory.typepad.com/papers/HostNumbers.pdf i.e. the
paper than explains why MAC addresses are 48 bits, "way to big" for what
you'd operationally need, as well as discussing some other general
network addressing issues)

So when you assign a /64 to a link in IPv6 (or /24 in IPv4, cable
number/range in Appletalk etc), you are saying that there might be
2^64 node addresses attached to the link. Or there might not be. You
certainly aren't saying they all are, or even if there were 2^64
assigned addresses, you're still not saying that they'll all be
available at the same time. 

Even when you assign a /31 to an IPv4 p2p link, or an IPv6 /127, you're
still only providing a hint. You're restricting the range of
available addresses on the link to one other, but you aren't saying it
has been assigned, or that it is available. A /31 assigned to only one
end of an operationally up p2p link between routers is functionally
valid, although usually operationally useless. In other words, IPv6
status information on one end of a P2P link implies, but doesn't 100%
constantly and accurately state IPv6 status information on the other
end of the link. To be trusted, it has to be tested.

Neighbor Discovery protocols (i.e. the NS/NA part of IPv6, AARP for
Appletalk etc.) perform two functions:

(1) verify remote layer 3 address assignment and availability

(2) for protocols that need it, provide layer 2 addressing information
for the queried layer 3 address


Neither is completely necessary in all scenarios. As you've said, (2)
isn't necessary on a P2P link that doesn't have layer 2 addresses.

(1) isn't completely necessary, unless you want to generate feedback to
the packet origin that it has sent a packet towards an unreachable
destination. IPv6 does generate those ICMPv6 messages, actually MUST
(from RFC4861, page 61) - 

"If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT
   solicitations, address resolution has failed.  The sender MUST return
   ICMP destination unreachable indications with code 3 (Address
   Unreachable) for each packet queued awaiting address resolution."

(The state created to be able to send back these ICMPv6 Address
Unreachables is the same state that the ND cache DoS is taking
advantage of.)

So if you need to to have IPv6 universally provide address
unreachable feedback messages, you need to have a neighbor discovery
protocol probe for addresses that are onlink targets, regardless of the
prefix length assigned to the link. That would even be the case if you
assigned /128s on each end of the link, and a static route for the
opposite /128 on the opposite router - because the router's local /128
static route could be wrong.

If you don't perform (1) on a P2P link, because (2) isn't
necessary, the local prefix and prefix length information, for any
prefix length (/64 through /127), is stating that all addresses within
the prefix are assigned and always available. While this is the common
situation with a /127s, as you shorten the prefix length, the less and
less accurate this statement becomes. A /64 on a P2P link is
atrociously inaccurate, unless the hint it provides is tested.

The ping-pong problem is a result of IPv6 routers on both ends of P2P
link with a /64 prefix are making this presumption of constant address
assignment and 100% availability. They aren't testing to see if a
neighbor exists before they try to send to it, and they each take turns
falling into the same trap.

/127s on P2P links mitigate this issue. That's fine for infrastructure
links like backbone SONET/SDH links. /127s aren't an option for
residential subscriber PPP/PPPoE P2P links, because the only practical
way to provide IPv6 services in that environment is to use either SLAAC
or Stateful DHCPv6, and they of course mandate /64s. There is going to
hundreds of thousands if not millions of those types of links services
around the world. Even though you can share a single /64
amongst multiple PPP sessions on a single router (i.e. an NBMA
hub-and-spoke structure), as you can on a Cisco, your business
customers, who'll probably want static IPv6 addresses on their ends of
their PPP session, regardless of the router they attach to, will require
static /64s per PPP session. 

The ping-pong remedy in RFC4443 is a solution, although if you
think about it, if address availability checking via Neighbor Discovery
was performed in the first place, the packet that is not "ponged back",
instead generating the ICMP Address Unreachable, would have never
arrived in the first place. 

(On related side note, RFC4443 should be mandatory in the simple CPE
draft. In the last few days, I've seen CPE that suffers from the ping
pong problem because it doesn't do Neighbor Discovery NS/NA on it's
PPP/PPPoE link, and hasn't implemented RFC4443.)

Regards,
Mark.