Subject: Re: I-D ACTION:draft-laganier-ipv6-khi-00.txt

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Sep 2005 11:46:55 +0200

In your previous mail you wrote:

   Couldn't find this being mentioned before, but I think it would be preferable
   if this section:
   
   ,----
   | 3.  Routing Considerations
   | 
   |    Keyed Hash Identifiers are designed to serve as identifiers rather
   |    than locators.  Therefore, routers SHOULD NOT forward any packets
   |    containing a KHI as a source or a destination address.  If the
   |    destination address is a KHI but the source address is a valid
   |    unicast source address, an ICMP Destination Unreachable,
   |    Administratively Prohibited message MAY be generated.
   | 
   |    Note that while KHIs are designed to be non-routable at the IP layer,
   |    there are ongoing research efforts for creating overlay routing for
   |    these kinds of identifiers.  For example, the Host Identity
   |    Indirection Infrastructure (Hi3) proposal outlines a way for using a
   |    Distributed Hash Table to forward HIP packets based on the Host
   |    Identity Tag.
   `----
   
   was rewritten a lot more like RFC3849 (IPv6 Docu Prefix), Section 3
   Operational Implications.
   
=> IMHO you'd like to have a more concrete operational recommendation.

   And, for example, added to:
   http://www.space.net/~gert/RIPE/ipv6-filters.html
   
=> this can be done only with the real prefix...

Thanks

[email-masked]

PS: the text from RFC 3849 is:

3.  Operational Implications

   This assignment implies that IPv6 network operators should add this
   address prefix to the list of non-routeable IPv6 address space, and
   if packet filters are deployed, then this address prefix should be
   added to packet filters.

   This is not a local-use address prefix, and the filters may be used
   in both local and public contexts.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Alun Evans <[email-masked]>
Date: Mon, 26 Sep 2005 11:47:45 +0100

Francis,

> => IMHO you'd like to have a more concrete operational recommendation.

Yes, but I'd meant as opposed to a mandate that "routers SHOULD NOT
forward"...

I'd think that most routers currently only know about link-local, multicast,
unspecified and loop-back addresses in the forwarding path.

RFC3849 doesn't mention routers, i.e. it's perfectly valid for a router to
forward a packet with a src/dst within the prefix. The onus is on the operator
to filter the prefix.

A.

-- 
Alun Evans
IOS Software Engineer, cisco Systems.
http://www.cisco.com/go/ipv6/

---

From: Alun Evans <[email-masked]>
Date: Mon, 26 Sep 2005 10:08:43 +0100

,----

There's kinda a lot of routers already deployed...

Alun.

-- 
Alun Evans
IOS Software Engineer, Cisco Systems Ltd,
250 Longwater Avenue, Reading. RG26 6GB. UK

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Sep 2005 13:51:43 +0200

RFC3849 doesn't mention routers, i.e. it's perfectly valid for a router to
   forward a packet with a src/dst within the prefix. The onus is on
   the operator to filter the prefix.
   
=> RFC 3849 is different because it wants to limit the scope of the
doc prefix. In KHI we simply don't want to see the prefix in IP headers
so the requirement (don't route) is stronger than filtering.

Thanks

---

From: Alun Evans <[email-masked]>
Date: Mon, 26 Sep 2005 13:42:00 +0100

Francis,

> so the requirement (don't route) is stronger than filtering.

RFC 3849 seems to be very similar imho, as it suggests using packet filters to
stop forwarding, as well as filtering the prefix from routing.

You shouldn't see the documentation prefix in the src or dst of any packet.

,----[RFC 3849]----
| 3.  Operational Implications
| 
|    This assignment implies that IPv6 network operators should add this
|    address prefix to the list of non-routeable IPv6 address space, and
|    if packet filters are deployed, then this address prefix should be
|    added to packet filters.
`----

If you filter traffic and routes at the edge of the DFZ, I think you'd get the
desired behaviour.

Placing a requirement directly on routers is a lot tougher than placing a
requirement on the operators. To support the current wording, every router
vendor would have to update their code, and then every customer would have to
upgrade every single router. This of course, would then have to be possibly
undone come January 1st 2009.

I think it is better to say that routers must be configurable with a wide
range of options, which allow the operators to accomplish these tasks.

Furthermore, it's nicer to keep the core forwarding simple, and put the
intelligence towards the edge of the network.

A.

---

From: Francis Dupont <[email-masked]>
Date: Mon, 26 Sep 2005 14:57:50 +0200

> so the requirement (don't route) is stronger than filtering.
   
   RFC 3849 seems to be very similar imho, as it suggests using packet
   filters to stop forwarding, as well as filtering the prefix from routing.
   
=> RFC 3849 implements a limit (so your term stop is not fully correct),
KHI implements an interdiction.

=> this is not true at all: inside a documentation site the documentation
prefix is virtually routed. BTW it is not a /64 but a /32.

   Placing a requirement directly on routers is a lot tougher than placing a
   requirement on the operators. To support the current wording, every router
   vendor would have to update their code,

=> no, this needs only configuration.

   Furthermore, it's nicer to keep the core forwarding simple

=> it is kept simple and BTW the routing table is not hardwired....

Regards

PS: there is something called "martian networks", RFC 3849 and KHI
are implemented both by putting the relevant prefix into this list.
The only difference is the doc prefix is in the list *by default*.

---

From: Pekka Nikander <[email-masked]>
Date: Mon, 26 Sep 2005 15:05:01 +0200

Avun,

> but I think it would be preferable
> if this section:
>
> ,----

I am really open to changing the wording; please provide a ready  
thought suggestion.

> undone come January 1st 2009.

What comes this concern, I tried to write the text in such a way that  
a simple configuration change would be sufficient, i.e., configure  
the router not to forward the packets, and possibly have it return  
ICMP unreachable.  I certainly didn't intend to require routers to be  
changed; that is unrealistic.

Indeed, if the prefix was allocated from 1000::/4 as suggested, then  
I think most router configurations would already now do the right  
thing.  But I may also be way off here; I'm mostly out of touch with  
current IPv6 operational matters.

--Pekka Nikander

---

From: Alun Evans <[email-masked]>
Date: Mon, 26 Sep 2005 16:01:41 +0100

Pekka,

On Mon 26 Sep '05 at 14:05 Pekka Nikander <[email-masked]> wrote:
> 
> Avun,
>
>> but I think it would be preferable if this section:
>>
>> ,----
>> vendor would have to update their code, and then every customer would have
>> to upgrade every single router. This of course, would then have to be
>> possibly undone come January 1st 2009.
>

Excellent! That was the concern I'd had about the wording.

c.f. the RFC 3513 (Address Arch) loop-back and unspecified checks which are
hard-coded in.

> Indeed, if the prefix was allocated from 1000::/4 as suggested, then I think
> most router configurations would already now do the right thing.  But I may
> also be way off here; I'm mostly out of touch with current IPv6 operational
> matters.

I think you are almost correct.

Following Gert's rules [http://www.space.net/~gert/RIPE/ipv6-filters.html]
1000::/4 would certainly be non-routeable.

However, that would only result in an ICMPv6 Destination Unreachable, No
Route.

As for the source address, I think it's likely the operator would be using
RPF, which is a silent drop for us.

You could just pull in the text from the Documentation Prefix RFC:

3.  Routing Considerations

   Keyed Hash Identifiers are designed to serve as identifiers rather than
   locators.  Therefore, IPv6 network operators SHOULD add the KHI prefixes to
   the list of non-routeable IPv6 address space, and if packet filters are
   deployed, then this address prefix should be added to packet filters.

Thus if the router generating the default route has a packet filter, you'd get
the desired behaviour with respect to the Admin Prohibited message.

However, I'd think it unlikely that packet filters are deployed, I
think operators tend to rely on Forward and Reverse lookups.

A.

---

From: Alun Evans <[email-masked]>
Date: Mon, 26 Sep 2005 16:07:51 +0100

Francis,

,----[RFC 3849]----

Packet filters are an interdiction; a deny typically always sends an ICMPv6
Destination Unreachable, Admin Prohibited.

> prefix is virtually routed. BTW it is not a /64 but a /32.

I should have been clearer, inside the DFZ you shouldn't see the documentation
prefix.

You also probably shouldn't see it within a site, but that's why the RFC
recommends adding it to filters, to stop it leaking out.

> => no, this needs only configuration.

I'm glad that was the intended behaviour.

A.