Subject: [OPSEC] Feedback on draft-ietf-opsec-lla-only-01

From: Benoit Claise <[email-masked]>
Date: Mon, 01 Oct 2012 11:10:56 +0200

Dear all,

I discussed one topic off line with Eric, regarding 
http://tools.ietf.org/html/draft-ietf-opsec-lla-only-01
For the sake of openness, here it is again on the list.

One on hand, the draft mentions:

    Lower configuration complexity: LLAs require no specific
    configuration, thereby lowering the complexity and size of router
    configurations.  This also reduces the likelihood of configuration
    mistakes.

On the other hand, the draft mentions:

    These link-local addresses SHOULD be hard-coded to prevent the change
    of EUI-64 addresses when changing of MAC address (such as after
    changing a network interface card).

So the question is: who is going to configure this? If the NMS, there is 
not much of a gain in term of lower configuration complexity.

We discussed the possibility of a global config on the router, for which 
the link-local addresses for that router would be generated from the UUID.

Regards, Benoit

---

From: "Ivan Pepelnjak" <[email-masked]>
Date: Mon, 1 Oct 2012 12:07:57 +0200

As far as intra-AS infrastructure links are concerned, I'm perfectly fine with the draft.

HOWEVER, EBGP is a huge can of worms. While we can definitely make EBGP work over link-local addresses, the interface name becomes part of EBGP neighbor ID (at least in Cisco IOS), leading to a nightmare scenario if you have to move the peering (or worse: IXP) link to another interface in hurry. At least Junos has configuration identifier renaming functionality ...

Hallway discussions with a few IXP operators and IXP members during last week's RIPE65 also indicated some lack of enthusiasm for this idea. I know the sample was statistically irrelevant, but it was clear not everyone wholeheartedly embraces EBGP-over-LLA concept.

Ivan

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Benoit Claise
> Sent: Monday, October 01, 2012 11:11 AM
> To: [email-masked]
> Subject: [OPSEC] Feedback on draft-ietf-opsec-lla-only-01
> 
> Dear all,
> 
> _______________________________________________
> OPSEC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsec

---

From: Gert Doering <[email-masked]>
Date: Mon, 1 Oct 2012 12:43:33 +0200

Hi,

> Hallway discussions with a few IXP operators and IXP members during last week's RIPE65 also indicated some lack of enthusiasm for this idea. I know the sample was statistically irrelevant, but it w…

Call me old-fashioned and IPv4-minded, but I *like* having well-defined
transit networks at IXPs.  With addresses I can ping from my desktop to
see whether something is broken, for example, or verify with a quick
traceroute to see which of multiple paths between us and a remote network
a packet is taking (consider one router being connected to two exchange
points - maybe not a typical case, but we have that, and we see some
peers on both IXPs).

I consider LLAs as useful for protocols with automatic neighbour discovery
(OSPFv3 and such), but for BGP, and network monitoring it's more hindrance 
than benefit.

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: Paul Ebersman <[email-masked]>
Date: Mon, 01 Oct 2012 16:20:23 +0400

ipepelnjak> Hallway discussions with a few IXP operators and IXP members
ipepelnjak> during last week's RIPE65 also indicated some lack of
ipepelnjak> enthusiasm for this idea. I know the sample was
ipepelnjak> statistically irrelevant, but it was clear not everyone
ipepelnjak> wholeheartedly embraces EBGP-over-LLA concept.

Seem to recall less than enthusiastic response from operators at IETF
and NANOG too. Breaks tools and debugging procedures for too many folks,
with massive retraining of NOCs for too little improvement in security.