IPv6 network policies

[Ole Troan]

Mark,

> 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.


so you didn't get this reply from April 13?

From: 	Ole Troan <otroan at employees.org>
Subject: 	Re: IPv6 network policies
Date: 	April 13, 2010 0:45:29  GMT+02:00
To: 	Mark Smith <nanog at 85d5b20a518b8f6864949bd940457dc124746ddc.nosense.org>

Mark,

[...]

> 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.

the prefix-length used says nothing about which other nodes exist on the link or which addresses they may use. the prefix-length or subnet information is only used for onlink determination.

so I wouldn't consider the prefix length as a hint of anything. you can obviously guess the other end's address if the prefix length was /127, but that's more of an artifact.

> 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

yes. probably better with the term "reachability" to cover this.

> (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.

in that case they could hardly be considered on-link.

> 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.

in my view this is entirely independent of the prefix length.

> 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.

no, they just forward packets following the routing table doing a longest match on the destination.
again this is independent of the prefix length used. this does hit an ICMP redirect exception case of course, since the packet will be sent out the same interface as it arrived. which is the solution offered by RFC4443.

> /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. 

agree, a /127 is not an acceptable workaround for this case. assuming you knew there was a router on the other end you don't have to use global addresses on the link at all.

> 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. 

that's correct.

> (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.)

yes, we should probably add that requirement. it has passed WG last call, but let me see if we can get it in. do you have proposed text?

as I said on the list, if you want to change the behaviour of IPv6 to always use ND before communicating to on-link nodes on any type of link, then you need to write a draft. plan to?
I would not object to such a solution.

cheers,
Ole