Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt

[Mark Smith <ipng@69706e6720323030352d30312d31340a.nosense.org>]

Hi Stig,

On Mon, 25 Jul 2005 10:29:42 +0200
Stig Venaas <Stig.Venaas@uninett.no> wrote:

> On Mon, Jun 27, 2005 at 06:22:17PM +0930, Mark Smith wrote:
> > Hi,
> > 
<snip>

 > 
> > It looks like a /128 prefix length is not permitted on an interface,
> > according to draft-ietf-ipv6-addr-arch-v4-04.txt, which I think means
> > most of the issues I was concerned about described disappear.
> 
> You're refering to 2.5.1 where it says
> 
>    For all unicast addresses, except those that start with binary value
>    000, Interface IDs are required to be 64 bits long and to be
>    constructed in Modified EUI-64 format.
> 
> I guess. I can't say I like this. I believe it's quite common in IPv6
> to use /128 for addresses on loopback interfaces on routers and inject
> those into IGP (just like IPv4 /32). If I understand this correctly,
> one would then be forced to use a different /64 for each router loopback.

I'd interpret it that way.

> It's also pretty common to use a longer than 64 prefix for tunnels, e.g.
> /126.
> 
> Is strictly speaking an interface identifier always needed? As it says
> in 2.5.1 it's used to identify interfaces on a link, but for loopback
> there isn't really any link... You wouldn't need to do ND etc for the
> loopback addresses.
> 

That's a good point.

Generally, the prefix length on an interface address assignment
indicates what destinations are on-link or offlink, although with IPv6,
unlike IPv4, ICMP redirects for a link router can also indicate that
"offlink" destinations, ie. those that don't fall within the host's
currently known /64s, are actually onlink, at a host level.

With a loopback (assigned either a /128 or just a /64), all other
destinations are offlink, and obviously there aren't going to be any
routers on the loopback "link" to correct any wrong offlink assumptions
via an ICMP redirect.

From what I've read in Christian Huitema's "IPv6 - The New Internet
Protocol", and what I remember of it, the origins of the /64 length were
some discussions of the idea of being able to swap the top 64 bits at
routing domain boundaries, allowing for easy re-addressesing, proposed
by Mike O'Dell. The book indicates that that idea wasn't fully agreed
with, however it did cause the /64 boundary to be put in place in case
something like that idea could be useful in the future. I don't remember
enough about the reasons for the /64 boundary, I wonder if using /128s
on loopbacks would contradict them. Some of the arguments against /127s
on point-to-point links in RFC3627 "Use of /127 Prefix Length Between
Routers Considered Harmful" may be worth considering in the context of
/128s on loopbacks.

Regarding loopbacks, irrespective of whether they are assigned a /128 or
a /64, I'd guess the loopback interface would never see any RAs from any
routers at all, which means that any automated RA address assignment /
renumbering mechanisms e.g., prefix lifetimes, etc., won't be able to be
used on them either.

> > I'm still not sure exactly how host routing would work from the
> > end-nodes point of view, so I'll continue to do some reading. It seems
> > to me that hiding the network or subnet topology by not grouping IPv6
> > addresses according to their common data links means that the subnet bit
> > portion of the address loses its significance when determining whether a
> > destination address is off or onlink, during Neighbour Discovery.
> 
> The way I see it the hosts would have physical interfaces connected to a
> physical link and have addresses for those doing ND etc as usual. In
> addition they would have some kind of virtual interface with some /128
> addresses and somehow inject host routes for those on the physical
> interfaces so that next-hop would be the (e.g. /64) addresses on the
> physical links. This is how I believe it works today when you use
> loopbacks with /128 for routers.
>

I think that would work. However, even if it is accepted to run some
form of routing protocol on the end-nodes to push host routes into the
routing cloud, there would still have to be a manual address assignment
process for the /128s on the loopback interfaces, because as you
mentioned before, the loopback interfaces probably won't receive any ND
protocol messages such as RAs. That could arguably be considered an
impractical solution "in this day and age", because staticly configured
addresses on hosts in IPv6 is so pre-DHCP IPv4 :-)

To hide the network topology from nodes external to this network domain,
then I'd think the /64s assigned to the links would have to be ULAs,
although I think the link-local addresses might be enough to support
forwarding the packets from the edge of the routing domain to the host
within it and vice-versa. The problem there though is that any ICMP
messages generated by routers, targeted towards external nodes, such as
Destination Unreachables, Packet Too Big would have "private" source
addresses, and would likely to be dropped by the routers at the edge
that are using source address filtering to prevent things like SYN
attacks. IOW, the same problems that occur now if somebody uses RFC1918
private addresses on their internal links.

I suppose as long as all the routers as well had /128s on loopback
addresses (not a bad idea at all), and as long as the ICMP messages used
the loopback addresses as the source addresses, that problem might not
occur.

Regards,
Mark.