Subject: [v6ops] New Draft: Using Only Link-Local Address in Network Core

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Thu, 8 Mar 2012 10:56:18 +0100

V6ops WG, 

Eric and myself published a new draft, which is in the context of v6ops.
We'd like to solicit feedback. 

We feel there are substantial advantages to only using link-local
addresses on core links, and propose this model as a "best common
practice". However, there are some caveats. 

Our draft lists advantages and disadvantages to allow network operators
to make a factual decision on whether this model fits their needs. 

Feedback?
Michael

http://wiki.tools.ietf.org/html/draft-behringer-lla-only-00

> --
>             Using Only Link-Local Address in Network Core
>                      draft-behringer-lla-only-00
> 
> Abstract
> 
>   This document proposes to use only IPv6 link-local addresses on
>   infrastructure links between routers, wherever possible.  It
>   discusses the advantages and disadvantages of this approach to aide
>   the decision process for a given network,
> --

---

From: Mohacsi Janos <[email-masked]>
Date: Thu, 8 Mar 2012 17:35:35 +0100 (CET)

Hi Michael,

 	We are using such a setup for more than 6-8 years now. I always 
talking advantages and disadvantages of using link-local addresses on 
various IPv6 tutorial. I did not think it should have been documented as a 
draft, but if you think worth it, I can support it. (NB: are there any 
draft to use private IPv4 addresses in the Network Core? )

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

On Thu, 8 Mar 2012, Michael Behringer (mbehring) wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 9 Mar 2012 01:39:32 +0900

> Feedback?

"We therefore conclude that it is possible to construct a working network
in this way."

Did you conclude so by building a working network, or did you just conclude
so while writing this draft? :->

But yes, it works. I've designed a network or two in this way over the
years, and I'm sure I'm not the only one.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 8 Mar 2012 10:41:27 -0600

Janos,

Good point. 

IMO, it is well worth documenting it as BCP.

I would shy away from comparing LL with private IPv4. I would argue that
using LL brings interesting set of challenges that never existed with
private IPv4.
So, it is important to document those challenges (and possible
workarounds) while considering LL-only. BCP is a good venue for that.

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Mohacsi Janos
> Sent: Thursday, March 08, 2012 11:36 AM
> To: Michael Behringer (mbehring)
> Cc: [email-masked]
> Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in
Network
> Core

---

From: [email-masked]
Date: Thu, 08 Mar 2012 17:58:05 +0100 (CET)

> draft to use private IPv4 addresses in the Network Core? )

There are several networks using private IPv4 addresses in the network
core. This often breaks traceroute, since the ICMP replies tend to be
sourced using the (private) interface address and many *other* networks
block private IPv4 addresses at the borders.

Also, a private IPv4 address is of course semantically different from a
link-local address.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Mar 2012 18:30:38 +0100

Hi,

> to make a factual decision on whether this model fits their needs. 

It might make sense for some, but I would oppose to make this a BCP
(which is another word for "we recommend that everbody does this").

We *like* using global scoped IPv4 and IPv6 addresses everywhere, because
it helps a lot with diagnostics ("traceroute will tell you, which of the
4 possible links the packet traverses", "be able to run ping tests from 
your monitoring box to specific interfaces, to see if *this* link is up").

Of course you need iACLs if you do that.

> >   the decision process for a given network,

I'm perfectly fine with that abstract.  I just want to be sure that 
this practice isn't advocated as a BCP to do so (because next thing our 
customers or some crazy auditors will tell us that we do it all wrong).

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Chuck Anderson <[email-masked]>
Date: Thu, 8 Mar 2012 12:37:12 -0500

> customers or some crazy auditors will tell us that we do it all wrong).

Perhaps the draft could be reworked to be a comparison and overview of
both techniques, LLA and global addressing, and their pros/cons
without having a position/recommendation/BCP for either method.

---

From: Gert Doering <[email-masked]>
Date: Thu, 8 Mar 2012 18:55:26 +0100

Hi,

> without having a position/recommendation/BCP for either method.

Without having read the draft yet - this format is something I would
be perfectly happy with, and having a conclusive list of pros/cons
to point people at to help decisions would certainly be useful.

Well, now it's obviously at me to actually read it and provide 
somewhat more complete feedback than "read the word BCP and start
screaming" :-)

Gert Doering
        -- NetMaster

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 09 Mar 2012 08:31:25 +1300

> to point people at to help decisions would certainly be useful.

Agreed. I haven't actually *read* the draft yet, but this did catch my
eye:

>>    ICMPv6 [RFC4443] error messages (packet-too-big...) are required for
>>    routers, therefore a loopback interface must be configured with a
>>    global scope IPv6 address.  This global scope IPv6 address will be
>>    used as the source IPv6 address for all generated ICMPv6 messages.

I'm glad to see that and it merits a MUST in some normative document,
even if this one is not a BCP.

On the same point:

>>    Traceroute: Similar to the ping case, a reply to a traceroute packet
>>    would come from a loopback address with a global address.  Today this
>>    does not display the specific interface the packets came in on.  Also
>>    here, RFC5837 [RFC5837] provides a solution.

There is a genuine source of confusion possible here for a typical
traceroute user, even if not interested in the specific interface.
I've seen cases where the traceroute reply came from a global address
that was actually a PA address from an ISP that was not actually
on the path, because the router had multiple interfaces with PA
addresses from several ISPs. So it's actually important that the
global address used for ICMP replies, even if it's a loopback address,
is under a prefix that belongs to the organisation operating the router
in question.

  Brian

---

From: "George, Wes" <[email-masked]>
Date: Thu, 8 Mar 2012 14:33:58 -0500

The proposed comparison already pretty much exists within a draft written and being adopted in GROW.

http://tools.ietf.org/html/draft-kirkham-private-ip-sp-cores-02

I'm thinking that perhaps the authors of the two drafts need to get together and either bolster the discussion around IPv6 and link-local in the current Kirkham draft, or turn this new draft into a companion document to -kirkham so that we end up with two non-overlapping drafts, one that covers IPv4 and one that covers IPv6 with a similar format.

Thanks,

Wes George

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Chuck Anderson
> Sent: Thursday, March 08, 2012 12:37 PM
> To: [email-masked]
> Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network Core
>

> without having a position/recommendation/BCP for either method.

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Thu, 8 Mar 2012 14:29:05 -0600

Brian,

> is under a prefix that belongs to the organisation operating the
router

Good point. This is worth adding in the next revision. 

> even if this one is not a BCP.

Sure, it could be informational.
But why would we not want it to be a BCP?  

Cheers
Rajiv

> Of Brian E Carpenter
> Sent: Thursday, March 08, 2012 2:31 PM
> To: Gert Doering
> Cc: [email-masked]
Network

---

From: [email-masked]
Date: Thu, 08 Mar 2012 22:09:21 +0100 (CET)

> But why would we not want it to be a BCP?  

Because there *is* no agreement that this is "Best current practice"?

I'm with Gert here - I want my links to have global addresses.

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 8 Mar 2012 23:23:23 +0100

>is under a prefix that belongs to the organisation operating the router

Also Passive-IPv6 addresses provide a way to have traceroute
capabilities again to complement a LL-only infrastructure.
(http://tools.ietf.org/html/draft-baker-opsec-passive-ip-address-00)
The convenient element is that it doesn't require the ICMP stack to be
changed and is box only behavior

G/

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 9 Mar 2012 09:20:03 +0900

> without having a position/recommendation/BCP for either method.

 +1.

For me, what makes this attractive is the operational simplicity. If you
don't number links, you can never make a mistake numbering them, you never
have to configure them, etc. All you need to do is enable IPv6 packet
processing on all interfaces and that's it. This is much simpler than IPv4,
where you can end up blackholing traffic if you don't assign all your
interfaces IP addresses.

---

From: Randy Bush <[email-masked]>
Date: Fri, 09 Mar 2012 19:17:44 +0900

> But why would we not want it to be a BCP?  

because the B stands for Best, not Bad.  we kinda like traceroute, ping,
and other diagnostic tools to be useful.  debug is horrible enough and
primitive as it goes today.  do not recommend screwing up what tools we
have.

randy

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Fri, 9 Mar 2012 14:23:01 +0100

I agree with Randy from a diagnostic perspective, however it does not
mean that LL-only is a bad philosophy from a security perspective. 

traceroute info can be fixed with passive IPv6 addresses, without adding
an additional attack vector above LL-only.
Ping in that case could result in people removing the passive out of
'ipv6 address 2001:db8::1/64 passive" cli on that interface. There is no
need to implement new protocols at all at any side of the equation.

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Randy Bush
Sent: vrijdag 9 maart 2012 11:18
To: Rajiv Asati (rajiva)
Cc: [email-masked]
Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network
Core

randy

---

From: Victor Kuarsingh <[email-masked]>
Date: Fri, 09 Mar 2012 09:55:10 -0500

>primitive as it goes today.  do not recommend screwing up what tools we
 
I will tend to agree (partially) with Randy here.  I think a BCP would
note that we are recommending a certain type of deployment or mode of
operation.

Whereas I don't disagree that LL-only is a useful model in some
circumstances, I don't think we can say it applies uniformly to all
networks and network conditions.  Therefore making it a BCP may be a bit
pre-mature.  

Regards,

Victor K

---

From: Mohacsi Janos <[email-masked]>
Date: Fri, 9 Mar 2012 17:11:33 +0100 (CET)

> networks and network conditions.  Therefore making it a BCP may be a bit

I prefer informational draft - describing advantages and disadvantages.
 	Regards,
 		Janos Mohacsi

---

From: Arturo Servin <[email-masked]>
Date: Fri, 9 Mar 2012 18:36:26 -0600

Janos,

 draft-ietf-grow-private-ip-sp-cores-00

Regards,
.as

On 8 Mar 2012, at 10:35, Mohacsi Janos wrote:

> Hi Michael,
> 
> 	We are using such a setup for more than 6-8 years now. I always talking advantages and disadvantages of using link-local addresses on various IPv6 tutorial. I did not think it should have been documented as a draft, but if you think worth it, I can support it. (NB: are there any draft to use private IPv4 addresses in the Network Core? )
> 
> Janos Mohacsi
> Head of HBONE+ project

---

From: Vízdal Aleš <[email-masked]>
Date: Wed, 14 Mar 2012 11:46:54 +0100

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Rajiv
> Asati (rajiva)
> Sent: Thursday, March 08, 2012 9:29 PM
> To: Brian E Carpenter; Gert Doering
> Cc: [email-masked]
 
> But why would we not want it to be a BCP?

Because it does not seem to be widely adopted as the BCP, an informational track would suit it better.

> Rajiv

Cheers,
Ales

---

From: Jen Linkova <[email-masked]>
Date: Tue, 20 Mar 2012 23:47:02 +1100

Hi Michael,

> to make a factual decision on whether this model fits their needs.

The suggested design does look very elegant, it does work but I have a
few comments:
- as it has been mentioned before, troubleshooting/diagnostic tools
could get broken (unless we are 100% sure that address selection works
as expected which isn't a case currently :((

- one of caveats not mentioned in the doc: let's say I have two links
between two routers and I need to construct a *strict* ERO for an LSP
to control which link is used.

Speaking of advantages:
"If a network only uses
   loopback addresses for the routers, only those loopback addresses
   need to be protected from outside the network." - if loopbacks are
addressed from the same block as core links, I don't believe using LLA
only would simplify your filters significantly. You'd probably have
the same policy for loopbacks as for core links anyway.

---
SY, Jen Linkova aka Furry

---

From: Rajiv Asati <[email-masked]>
Date: Wed, 21 Mar 2012 17:26:08 -0400

Jen,

Thanks for the feedback.

It is reasonable to say that troubleshooting/diagnostics tools (e.g. Ping,
trace route, ftp, syslogŠ) would work just fine, if their source address
is hardcoded to a particular GUA (instead of relying on automagical SAS).

Good point on the caveat about RSVP-TE. That one, along with few more,
should be there in the next revision.

Wrt the last point, it is a common practice to dedicate a particular
subnet for the loopbacks. So, a single policy wouldn't cut it in that case.

Cheers
Rajiv

-----Original Message-----
From: Jen Linkova <[email-masked]>
Date: Tue, 20 Mar 2012 23:47:02 +1100
To: "Michael Behringer (mbehring)" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network
Core

---

From: Gert Doering <[email-masked]>
Date: Thu, 22 Mar 2012 12:39:42 +0100

Hi,

> subnet for the loopbacks. So, a single policy wouldn't cut it in that case.

Dedicate a larger subnet (like, "a /48") for loopbacks + transit.  

Still single policy.

Gert Doering
        -- NetMaster

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 22 Mar 2012 13:48:46 +0100

I Agree with Gert.

The simplicity is into making sure that teh policy doesn't have to be
changed every week for example, but only maybe once every 2 a 3 years...

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Gert Doering
Sent: donderdag 22 maart 2012 12:40
To: Rajiv Asati (rajiva)
Cc: [email-masked]; Michael Behringer (mbehring)
Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network
Core

Hi,

Still single policy.

Gert Doering
        -- NetMaster

Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A.
Grundner-Culemann

---

From: Rajiv Asati <[email-masked]>
Date: Thu, 22 Mar 2012 09:46:40 -0400

Yah, in that case, I agree.

-----Original Message-----
From: Gert Doering <[email-masked]>
Date: Thu, 22 Mar 2012 12:39:42 +0100
To: Rajiv Asati <[email-masked]>
Cc: Jen Linkova <[email-masked]>, "Michael Behringer (mbehring)"
<[email-masked]>, <[email-masked]>
Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network
Core

---

From: Tina TSOU <[email-masked]>
Date: Fri, 23 Mar 2012 03:15:21 +0000

Link-Local Address can not be used in CE router or even lower position of enterprise service?

Sent from my iPad

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Fri, 23 Mar 2012 11:13:45 +0100

Why?

As long as CE gets a PD prefix for its users at home, then that should
work just fine, not?

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Tina TSOU
Sent: vrijdag 23 maart 2012 4:15
To: Rajiv Asati (rajiva)
Cc: [email-masked]; Michael Behringer (mbehring)
Subject: Re: [v6ops] New Draft: Using Only Link-Local Address in Network
Core

Link-Local Address can not be used in CE router or even lower position
of enterprise service?

Sent from my iPad

Network
>>> subnet for the loopbacks. So, a single policy wouldn't cut it in
that
>>> case.

---

From: Mohacsi Janos <[email-masked]>
Date: Fri, 23 Mar 2012 14:07:03 +0100 (CET)

Dear all,

I Agree with Gunter. It is working. On my home router the addresses:

root@OpenWrt:~# ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
     inet 127.0.0.1/8 brd 127.255.255.255 scope host lo
     inet6 fd00::1/64 scope global
        valid_lft forever preferred_lft forever
     inet6 ::1/128 scope host
        valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state 
UP qlen 1000
     link/ether 00:24:01:6c:73:e6 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state 
UP qlen 1000
     link/ether 00:24:01:6c:73:e7 brd ff:ff:ff:ff:ff:ff
     inet xx.yy.23.1/30 brd xx.yy.23.3 scope global eth1
     inet6 fe80::224:1ff:fe6c:73e7/64 scope link
        valid_lft forever preferred_lft forever
4: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state 
UNKNOWN
     link/ether 00:24:01:6c:73:e6 brd ff:ff:ff:ff:ff:ff
     inet 192.168.0.1/24 brd 192.168.0.255 scope global br-lan
     inet6 2001:738:xxxx:yyyy:224:1ff:fe6c:73e6/64 scope global
        valid_lft forever preferred_lft forever
     inet6 fe80::224:1ff:fe6c:73e6/64 scope link
        valid_lft forever preferred_lft forever

The only global IPv6 address on interface 4: I got via DHCPv6-PD.

Best Regards,

Janos Mohacsi
Head of HBONE+ project
Network Engineer, Deputy Director Network and Multimedia
NIIF/HUNGARNET, HUNGARY
Co-chair of Hungarian IPv6 Forum
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

---

From: Don Sturek <[email-masked]>
Date: Fri, 23 Mar 2012 06:13:01 -0700

Hi Gunter,

There are several MAC/PHY technologies that don't support bridging (eg,
IEEE 802.15.4-2006, PLC solutions like G3, etc.).  Adding ROLL RPL as a
routing solution to these MAC/PHYs mean that link locals don't cover the
entire residence in scope.  Many homeowners don't want to rely on a global
prefix just to support local functions like finding a printer.  Hence the
requirement for ULAs in these settings......

Don