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

From: Mark Smith <[email-masked]>
Date: Fri, 1 Jul 2005 20:33:59 +0930

Hi Alain, Fred

On Thu, 30 Jun 2005 12:28:50 -0700 (PDT)
[email-masked] wrote:

> >
> > On Jun 27, 2005, at 9:52 AM, 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.
> >
> > For the record, a /32 is now permitted on an interface in IPv4. This
> > permits allocation of such to a loopback interface, for example. It may
> > be worthwhile to find the use cases for that and ask whether they apply
> > to IPv6.
> 

That's what started me down this path of wondering how host-routing on
the end-node worked.

Having used /32s on loopbacks on routers, I started wondering how
they'd work on physical interfaces. Mostly what you are taught about
IPv4 is that a router's IP address has to fall within the subnet
assigned to the link the node is attached to. Then you learn about host
routes and PPP, and find out that isn't necessarily the case.

I then started wondering how a /32 on an broadcast multi-access
interface would work e.g., an ethernet, and if ARP would resolve
addresses that were "offlink" according to the /32 prefix length,
including a directly attached default gateway, 

I haven't done a full test, however with the right static routes
(interface host route for a gateway address, default route point to that
gateway route), Linux will issue ARPs with payload source and
destination IP addresses that don't fall within a particular subnet. I'm
not sure if other devices will respond, maybe they will as long as the
don't perform checks on the subnet membership of the source and
destination addresses in the ARP.

> It is use a lot on servers to increase network reliability.
> Servers configure an IP address on the loopback, publish it in the DNS
> and advertize it via routing protocols.
> I do not see why it will not be used in v6 the exact same way.
> 

Certainly I'd think things should work within IPv6 in the same way.

There are a few inefficiencies in this model though :

(1) If the host only has one interface, using a nailed up loopback
doesn't add all that much value, and in the case of IPv6, costs a /64
subnet (as /128s aren't supposed to be used). Remote nodes may as well
send their traffic towards the (IPv4/IPv6) address assigned to the
physical interface itself.

(2) Running a fully fledged routing protocol on the end-node is
relatively heavy handed for what is being achieved. I'd think a
simple, light-weight announcement style availability protocol for the
node's address, that is part of IPv6 itself, would be useful. 

In the context of the NAP draft and the host routing, topology hiding
suggestion, if the addresses within a /48 aren't grouped into /64
prefixes, with those individual /64s assigned to an individual link, I
don't think the end-node can assume that an IPv6 destination is a link
layer peer even if the address falls within the /64 prefix assigned to
the probable outgoing interface. As only the routing protocol knows
where hosts are actually located in the topology, due the the host
routes, it seems that the end-nodes would need to always assume the
destination is offlink, and if the destination isn't, the router would
issue a redirect towards the link layer peer. From what I understand of
CLNS, this sounds remarkably similar to how it handles the offlink /
onlink destination issue.

Thinking about it more broadly, this topology hiding idea sounds
remarkably like CLNS / IS-IS Level 1 and Level 2 routing. For
sources/traffic outside the /48(s), forwarding is based on a best match
(as in CLNS/IS-IS Level 2 areas), once the traffic reaches the network
topology that falls within the /48, routing then becomes flat, exact
match against host routes to forward to the exact location of the host
(as in CLNS/IS-IS Level 1 areas). 

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Fri, 1 Jul 2005 22:01:21 +0930

On Fri, 1 Jul 2005 20:33:59 +0930

> (as in CLNS/IS-IS Level 2 areas),

To be clear, the above is meaning a "best, longest match".

> once the traffic reaches the network

---

From: Fred Baker <[email-masked]>
Date: Fri, 1 Jul 2005 08:25:03 -0700

> node's address, that is part of IPv6 itself, would be useful.

It was standard practice on DECNET, XNS, and Novell equipment; Novell 
did it twice, once for the routes and once for the services that the 
servers offered. If you have only one interface, as you say it didn't 
accomplish much. But if you have multiple interfaces on a server, it 
provides something akin to what multihoming does for a network. As you 
say, it is expensive in address count to put a /64 on a host, though.

In general, if you're interested in routing scaling, using the tools 
that make it scale are a good thing. Host routes are the exception, I 
should think, not the rule.

---

From: Mark Smith <[email-masked]>
Date: Sat, 2 Jul 2005 01:14:19 +0930

Hi Fred,

On Fri, 1 Jul 2005 08:25:03 -0700

> say, it is expensive in address count to put a /64 on a host, though.

It took many years for me to realise why there was an "internal network
number" on Novell servers :-) I think it probably co-incided with me
learning how /32s on loopbacks pushed into a routing cloud could be
useful for maintaining routers.

> should think, not the rule.

I generally agree, I personally don't really see all that much security
value in attempting to make the internal subnet topology opaque to
external devices at the cost of scalabilty. However, people seem to
like NAT because that is one if its properties, and I could see them
wanting to preserve it with IPv6. The NAP draft is suggesting
using host routes to do this, and how that will work in IPv6 has
intersected a bit with my somewhat academic interest in how it works on
broadcast interfaces with IPv4.

For those who do place value on topology hiding, I'd imagine it would
most likely to be "all-or-nothing" approach, meaning that all their
hosts within their assigned /48(s) would be host routed, rather than a
minor subset. If they think topology hiding is important, they're
probably also prepared to think it is important for all their nodes,
rather than a minor subset, and be willing to wear the scalability cost.

Regards,
Mark.

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 14 Jul 2005 11:58:14 -0700

To be clear, the NAP draft is offering host routes as one option for
topology opaqueness, and I recall a discussion about text suggesting there
would be scaling concerns with the IGP. Maybe that didn't make it in the
current version of the draft. The other option is to use mipv6 without route
optimization. The external nodes are talking to the home agent for the
virtual subnet and it uses the tunnel mode to get to the current care-of for
the device. This has a scaling impact on internal traffic volume due to the
tunnel header, but has absolutely no impact on routing. 

Tony 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mark Smith
> Sent: Friday, July 01, 2005 8:44 AM
> To: Fred Baker
> Cc: [email-masked]; [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-v6ops-nap-01.txt
> 
> Hi Fred,
>

---

From: Stig Venaas <[email-masked]>
Date: Mon, 25 Jul 2005 10:29:42 +0200

On Mon, Jun 27, 2005 at 06:22:17PM +0930, Mark Smith wrote:
> Hi,
> 
> On Sat, 18 Jun 2005 01:18:42 +0930
> > Hi,
> > "6.2  Subnet topology masking
> > 
> >       There really is no functional gap here as a centrally assigned
> >    pool of addresses in combination with host routes in the IGP is an
> >    effective way to mask topology. "
> > 
> > I'm wondering if the above is actually the case. 
> > 
> > I think host routes are easy enough to understand from the point of view
> > of propagating /128s around within an IGP. 
> > 
> > What I'm curious about is how the end-nodes are configured and how they
> > operate, in particular when they are attached to a broadcast
> > multi-access link e.g., an ethernet. Has this operation been discussed or
> > described in an ID or RFC that I'm not aware of ?
> > 
> 

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

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

Stig

> Thanks,

---

From: Stig Venaas <[email-masked]>
Date: Mon, 25 Jul 2005 12:57:52 +0200

On Mon, Jul 25, 2005 at 10:29:42AM +0200, Stig Venaas wrote:
[...]
> On Mon, Jun 27, 2005 at 06:22:17PM +0930, Mark Smith wrote:
[...]
> It's also pretty common to use a longer than 64 prefix for tunnels, e.g.

Come to think of it, is there anything preventing using the last 64 bits
of an address as an IID when it is /126 (/128 or whatever >64)? On say a
tunnel with /126, you would then have 64 bit IIDs that are unique to the
link because the last 2 bits are unique to the link.

Stig

---

From: Mark Smith <[email-masked]>
Date: Tue, 26 Jul 2005 00:20:55 +0930

Hi Stig,

On Mon, 25 Jul 2005 10:29:42 +0200

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

> one would then be forced to use a different /64 for each router loopback.

I'd interpret it that way.

> there isn't really any link... You wouldn't need to do ND etc for the

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.

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

---

From: Mark Smith <[email-masked]>
Date: Tue, 26 Jul 2005 00:27:27 +0930

Hi Stig,

On Mon, 25 Jul 2005 12:57:52 +0200

> link because the last 2 bits are unique to the link.

I'm not sure I fully understand what you're getting at here, are you
able to expand on it a bit more ?

In some of my thinking about this host routing issue, I realised that prefix
lengths on addresses assigned to interfaces actually indicate two things
:

- what portion of the address is the node address i.e., where the
boundary between the network and node parts falls

- what destination addresses are onlink or offlink

I think it would be possible to have those two values different for a
node's interface, although IPv6 doesn't separate them at the moment. Is
that something along the lines of what you're describing with your /126
tunnel suggestion ? 

Regards,
Mark.

---

From: "Mark K. Thompson" <[email-masked]>
Date: Tue, 26 Jul 2005 11:55:24 +0100

Hi Mark, Stig,

On 25 Jul 2005, at 15:50, Mark Smith wrote:

> Some of the arguments against /127s

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)

>>> end-nodes point of view

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  
DHCPv6 server-to-router signalling to have the host route injected to  
the local network, too?)

> within it and vice-versa.

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

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.

> the loopback addresses as the source addresses, that problem might not

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

---

From: Stig Venaas <[email-masked]>
Date: Tue, 26 Jul 2005 13:12:03 +0200

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

> 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  

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.

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

> masking the internal routing topology.

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

Stig

---

From: "Eric Klein" <[email-masked]>
Date: Tue, 26 Jul 2005 14:30:17 +0300

> hosts, not all the hosts in a site.

Although these are valid points, I would think that these DHCPv6 issues
should be brought up in relation to the DHCPv6 drafts rather than the NAP
one.

> insist on hiding their topology, then it should tell them how it can
The point of this draft was that NAT and topology hiding are not useful for
security and NAP via native IPv6 can better handle the security issues. This
is why we do not offer work arounds that bring back NAT topology hiding into
IPv6.

Eric

---

From: Stig Venaas <[email-masked]>
Date: Tue, 26 Jul 2005 17:36:11 +0200

> should be brought up in relation to the DHCPv6 drafts rather than the NAP

I only noted DHCPv6 in the first sentence. Everything I say about
injection is a general problem. Main point is that having host routes
for all hosts (or all that is to communicate with the outside) is not
really that easy in practise.

So as I'm saying, tunneling might be easier, which is basically what
the NAP draft suggests (using MIPv6).

> is why we do not offer work arounds that bring back NAT topology hiding into

But you try to offer work arounds by suggesting MIPv6, right? And the
question was whether other tunneling mechanisms or host routes could be
an alternative.

Stig