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

[Stig Venaas <Stig.Venaas@uninett.no>]

On Tue, Jul 26, 2005 at 11:55:24AM +0100, Mark K. Thompson wrote:
> Hi Mark, Stig,
> 
> On 25 Jul 2005, at 15:50, Mark Smith wrote:
> 
> >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:
> >>>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.
> >
> >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.
> 
> We use /112s for point-to-point links, following Pekka's argument in  
> RFC3627, and haven't yet (touch-wood) experienced any difficulties in  
> so doing.
> 
> However, we have tried to ensure that the u/g bits are set  
> appropriately as if they would have the EUI-64 specified meaning were  
> the addresses under a 64-bit prefix, so that should any  
> implementations blindly assume that node addresses have the bottom 64- 
> bits as an interface identifier, the semantics still hold.
> 
> Given that this is all under globally aggregatable unicast address  
> space, the topology is such that each /112 will be globally unique  
> and thus the bottom 64-bits unique also, and so the inferred  
> intention of the spec is still obeyed (that is: the bottom 64 bits of  
> the interface's address can be used as an identifier)

Right, I think so. This is more or less what I had in mind on my last
post yesterday. I think I should go back and re-read some of the RFCs
though.

> >>>I'm still not sure exactly how host routing would work from the
> >>>end-nodes point of view
> >>
> >>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 :-)
> 
> One solution might be a new DHCPv6 option to assign addresses on  
> interfaces other than the one we're using to send the DHCPv6 query  
> from. (What would that message look like? Is there scope for some  

I'm not sure I like that in general. One thing to consider in
general is doing DHCP on multiple links. But we're now talking about
virtual interfaces that are not connected to any links, so that's a
special case.

> DHCPv6 server-to-router signalling to have the host route injected to  
> the local network, too?)

There's been discussion regarding DHCPv6 PD and route injection. This
is sort of a degenerated case of that (:

I believe how to do injection is the biggest issue here. I don't quite
believe in all hosts in a site injection routes. Maybe some kind of
tunneling is easier.

Mechanisms for injecting host routes could be useful for people doing
anycast though. This is done today but then with just a few trusted
hosts, not all the hosts in a site.

I must say though that I never understood what one gains by hiding the
topology, and there's lots of complexity and pain related to this. I
guess the idea with NAP draft though is that if some silly people
insist on hiding their topology, then it should tell them how it can
be done.

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

ULAs? The question is what addresses you use for packets leaving the
site, right? ULA would hopefully mostly be used only internally.

> Better pray that you're not using multicast of scopes wider than 5,  
> then ;-) (RFC3484 default policy doesn't bode well when you're using  
> ULAs and multicast together - but that's a different discussion)
> 
> >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.
> 
> This is possibly one of the few cases where address translation is  
> desirable with IPv6: at the border router propagating errors outward,  
> masking the internal routing topology.

Address translation is never desirable. You don't want to rewrite
source addresses of packet too big.

> >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.
> 
> Taking traceroute as an example (and likely to be the first utility  
> about which users will complain about not returning useful  
> information...) - what is there to guarantee that the address used  
> for ICMP Time exceeded messages would be the global loopback address  
> of the reporting router, rather than it's ULA/private address of the  
> interface on which the message is generated?
> 
> 
> regards,
> 
> Mark/
> 
> --
> Dr Mark K. Thompson
> Electronics and Computer Science
> a School of the University of Southampton, UK

Stig