Subject: Source for ICMP on link-local-only interface?

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 9 Feb 2011 11:52:33 +0100

I've been telling people for years that with IPv6, you don't need a global scope address on an interface. The routing protocols use link locals, so they don't care. And should an ICMP message need to be generated, the source address is filled in with a global scope address borrowed from another interface that does have one.

However, I can't find any documentation for this behavior. Is there an RFC that specifies this as part of normal IPv6 router behavior?

Thanks,

Iljitsch

---

From: Ole Troan <[email-masked]>
Date: Wed, 9 Feb 2011 11:58:22 +0100

> However, I can't find any documentation for this behavior. Is there an RFC that specifies this as part of normal IPv6 router behavior?

weak host model. RFC1122.

cheers,
Ole

---

From: "Raymond Burkholder" <[email-masked]>
Date: Wed, 9 Feb 2011 06:58:24 -0400

> I've been telling people for years that with IPv6, you don't need a global
> scope address on an interface. The routing protocols use link locals, so
they
> don't care. And should an ICMP message need to be generated, the source
> address is filled in with a global scope address borrowed from another
> interface that does have one.
> 

One useful aspect of ICMP is in tracerouting, where you get an ip address of
a particular interface, and then through a reverse dns lookup, you get a
human readable name for the interface.  Very useful for troubleshooting
where errant packets are going.  Not very useful if you get a device
loop-back, resulting in some information being lost.  Or is there an
alternate mechanism for providing this level of detail in IPv6 traceroutes?

Raymond

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 9 Feb 2011 12:05:01 +0100 (CET)

On Wed, 9 Feb 2011, Iljitsch van Beijnum wrote:

> I've been telling people for years that with IPv6, you don't need a 
> global scope address on an interface. The routing protocols use link 
> locals, so they don't care. And should an ICMP message need to be 
> generated, the source address is filled in with a global scope address 
> borrowed from another interface that does have one.

I think it is part of source address selection:
destination is global scope, then the source should be global scope as 
well.

> However, I can't find any documentation for this behavior. Is there an RFC that specifies this as part of normal IPv6 router behavior?

I think this behaviour is not the router behaviour, but the router as a 
host. ICMP messages are generated by the host software. Which interface's 
global address is selected is depend probably on router software. e.g. 
first interface index with global address.

You can make it consistent with Cisco e.g.:
ipv6 unnumbered <specific interface>

Best Regards,

Janos Mohacsi
Head of HBONE+ project
Network Engineer, Deputy Director of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

>
> Thanks,
>
> Iljitsch
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 9 Feb 2011 12:15:09 +0100

> weak host model. RFC1122.

Hah, this RFC talks about "weak ES" and "strong ES" models. I'm not sure if that's politically correct considering what happened regarding CLNP and IPv6 only a few years after 1122 was published.

However, it doesn't say anything about this. Neither does RFC 4294, IPv6 Node Requirements, unless it's without using the words "source address", "interface" or "global" and under a very non-obvious heading. Same thing for 2460 - 2464, 3484, 3513.

---

From: Tore Anderson <[email-masked]>
Date: Wed, 09 Feb 2011 12:15:49 +0100

* Iljitsch van Beijnum

> The routing protocols use link locals, so they don't care.

BGP cannot possibly resolve a link-local next-hop, can it?

Best regards,
-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 9 Feb 2011 12:30:04 +0100

> BGP cannot possibly resolve a link-local next-hop, can it?

Not sure what you mean.

IPv6 BGP does in fact carry gloal and link local next hop addresses.

Of course most people will want to configure BGP using a shared prefix between the two routers because that's the easiest way to do it. But using loopback addresses isn't unheard of, because that way you can load balance across multiple interfaces without having to have a BGP session for each interface.

---

From: Tore Anderson <[email-masked]>
Date: Wed, 09 Feb 2011 12:40:22 +0100

* Iljitsch van Beijnum

> IPv6 BGP does in fact carry gloal and link local next hop addresses.

Yes, but my point is that if you don't configure a global (at least
non-link-local) prefix on the router interconnections, there's no global
address that can be announced as the BGP next-hop. With no global
address, the immediate link-local next-hop cannot be resolved in the
IGP, and the route is discarded. Or am I missing something?

For example, here's my BGP route to your e-mail domain. The key item
here is «Protocol next hop: 2a02:228:81:100::», which is the remote
router in the link-net to AS3292. If this link was numbered with
link-local addresses only, I don't see how this route could possibly be
used, unless you start mangling the BGP next-hop?

tore@cr2> show route 2001:1af8:2:5::2 active-path extensive    

inet6.0: 4377 destinations, 8940 routes (4376 active, 0 holddown, 1 hidden)
2001:1af8::/32 (3 entries, 1 announced)
TSI:
KRT in-kernel 2001:1af8::/32 -> {indirect(1048574)}
        *BGP    Preference: 170/-51
                Next hop type: Indirect
                Next-hop reference count: 5286
                Source: 2a02:c0:1000::2
                Next hop type: Router, Next hop index: 614
                Next hop: fe80::221:59ff:fe0e:9295 via xe-1/0/0.0, selected
                Protocol next hop: 2a02:228:81:100::
                Indirect next hop: 11355ac8 1048574
                State: <Active Int Ext>
                Local AS: 39029 Peer AS: 39029
                Age: 3:58:10 	Metric: 20 	Metric2: 2 	MED-plus-IGP: 22 
                Task: BGP_39029.2a02:c0:1000::2+179
                Announcement bits (2): 0-KRT 6-Resolve tree 4 
                AS path: 3292 16265 I
                AS path: Recorded
                Communities: 3292:1110 3292:24601
                Accepted
                Localpref: 50
                Router ID: 87.238.32.5
                Indirect next hops: 1
                        Protocol next hop: 2a02:228:81:100:: Metric: 2
                        Indirect next hop: 11355ac8 1048574
                        Indirect path forwarding next hops: 1
                                Next hop type: Router
                                Next hop: fe80::221:59ff:fe0e:9295 via xe-1/0/0.0
			2a02:228:81:100::/127 Originating RIB: inet6.0
			  Metric: 2			  Node path count: 1
			  Forwarding nexthops: 1
				Nexthop: fe80::221:59ff:fe0e:9295 via xe-1/0/0.0

---

From: Mohacsi Janos <[email-masked]>
Date: Wed, 9 Feb 2011 12:46:04 +0100 (CET)

On Wed, 9 Feb 2011, Tore Anderson wrote:

> here is ?Protocol next hop: 2a02:228:81:100::?, which is the remote

With C vendor there is a built in knob for mangling next-hop. In this case 
I don't like the idea of BGP with link-local:
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-mptcl_bgp.html#wp1037072

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 9 Feb 2011 12:46:40 +0100

> IGP, and the route is discarded. Or am I missing something?

Right.

Of course I was speaking about protocols like OSPF, which require that the routers to share a prefix for them to find each other with IPv4, but with IPv6 they don't because the routers communicate using link-locals.

I'm not sure if BGP implementations reject link locals as the mail BGP next hop address, or if they are smart enough to know that it can work across one hop but not more than one. It's still possible to make everything work by rewriting the next hop address (such as configuring next-hop-self). One situation where this could be useful is if you want to avoid providing a DoS target by running BGP over unroutable address space.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 9 Feb 2011 14:12:35 +0200 (EET)

> IGP, and the route is discarded. Or am I missing something?

FWIW, not that it would address your issue -- but about 9 years ago 
there existed draft-kato-bgp-ipv6-link-local-00, which proposed some 
mods to BGP in Section 3.  I vaguely recall that at least Juniper 
claims to support this.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Simon Perreault <[email-masked]>
Date: Wed, 09 Feb 2011 09:25:27 -0500

> BGP cannot possibly resolve a link-local next-hop, can it?

Here's how to do it on Cisco:
http://www.cisco.com/en/US/docs/ios/ipv6/configuration/guide/ip6-mptcl_bgp.html#wp1037072

It's "officially approved". ;)

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Francis Dupont <[email-masked]>
Date: Wed, 09 Feb 2011 18:15:00 +0100

In your previous mail you wrote:

   * Iljitsch van Beijnum

   
=> the issue was addressed years ago but this carefully wording:

   The link-local address shall be included in the Next Hop field if and
   only if the BGP speaker shares a common subnet with the entity
   identified by the global IPv6 address carried in the Network Address
   of Next Hop field and the peer the route is being advertised to.

Regards

[email-masked]

PS: this happened in the early days of both BGP v4 and IPv6:
the issue was considered to be hairy and particular to IPv6
so we asked for a dedicated document which was published later
as the RFC 2545.
PPS: if you like it, please ask for a promotion to the
Draft Standard status...