Re: [GROW] draft-behringer-lla-only and draft-ietf-grow-private-ip-sp-cores

["Michael Behringer (mbehring)" <[e-mail]>]

Wes, 

Thanks for your great input and sorry for the delay. In the meantime we have updated our draft to include many of your (and others') comments. (http://tools.ietf.org/html/draft-behringer-lla-only-01). Most importantly, we made it now an informational draft. 

We believe it is best to keep the drafts separate. There are important differences between private addresses and link local: One is routed, one is not; one needs to be configured, one not. We added however a xref to draft-ietf-grow-private-ip-sp-cores, because as you rightly comment, they are related.

We still think there is value in draft-behringer-lla-only. Bottom line, we want to provide a document presenting the issues and advantages that allows operators to make an educated decision whether link local is the right approach for them. 

We'll ask for slots in Vancouver at v6ops and opsec to discuss the new version. 

Eric and Michael

> -----Original Message-----
> From: George, Wes [mailto:[e-mail]]
> Sent: 31 March 2012 01:15
> To: [e-mail]; [e-mail]
> Cc: [e-mail]; Anthony Kirkham
> Subject: draft-behringer-lla-only and draft-ietf-grow-private-ip-sp-cores
> 	
> Cross-posting to both lists again because I was unable to attend the v6ops
> session where draft-behringer was discussed, draft-ietf-grow-private-ip-sp-
> cores is likely nearing WGLC, and I believe that the issue I raised needs to be
> addressed before either proceeds. I defer to the chairs of both groups to
> determine how to manage this across the two groups.
> 
> After reviewing both draft-grow-private-ip-sp-cores (Kirkham) and draft-
> behringer-lla-only again, I am even more convinced that they either need to
> be merged, or that draft-behringer needs to be abandoned altogether as a
> bad idea. Draft-grow-private-ip-sp-cores is quite a lot more complete in its
> discussion of the considerations around private IP usage, but focuses on
> IPv4, meaning that it *is* incomplete for lack of discussion of IPv6, which is
> a reality in most SP cores today. Nearly all of the same considerations apply
> for IPv4 and IPv6 in this case, so there are probably a limited number of
> changes that would be necessary to cover IPv6 in the Kirkham document.
> I think that we need to come to some consensus on the recommended
> behavior on both cases. If the recommendation is different for one versus
> the other, we need to have a unified and clear articulation as to why this is
> the case. It may be that the consensus is to not recommend a behavior at all,
> and simply expand the format of Kirkham's document to cover any IPv6-
> specific items, since it discusses pros and cons evenly (as an informational
> doc) rather than recommending anything as a BCP. My vote is to do this, as I
> am unconvinced that use of LLA represents BCP today, nor should it. I
> outline some reasons below, but that's probably not as critical if others
> agree that this is the proper method to proceed with these documents.
> 
> 
> 
> If draft-behringer is left as a separate document, here are some specific
> comments:
> The advantages proposed in draft-behringer are IMO not enough to justify
> recommending use of LLA.
> - Smaller routing tables can be achieved through other methods such as
> setting the interfaces into passive mode in the IGP (so that they are not
> redistributed into the IGP) and/or not redistributing connected routes.
> Further, as SPs make great use of interface bundling (LAG), the number of
> interfaces with IP addresses is dramatically reduced, making the need to
> pull the point to point interfaces out of the routing table significantly lower.
> - Reduced attack surface - draft-ietf-grow-private-ip-sp-cores sections 10
> and 11 discuss this in great detail, and come to the conclusion that it is of
> limited benefit, and that alternatives exist to protect the infrastructure.
> - lower configuration complexity - while this is true, it is replaced by
> additional complexity in troubleshooting. In the case of traces and pings
> locally on the box, it adds the additional step of requiring the operator to
> use extended ping and trace commands to specify the exit interface in order
> to make the ping work (vs simply issuing "ping [ip address]"), and makes it
> nearly impossible to derive the address of the remote interface without
> determining the remote side router through some other means and logging
> into the router to look. (vs practice today of using an IP in the same subnet,
> usually 1 digit up or down that can be guessed to save time).
> - less address space: The other draft mentions this as well, in the context of
> IPv4 where it might make a difference, but this simply is not much of a
> concern with IPv6. An entire network could be numbered many times over
> out of one /64.
> -simpler DNS : Most ISPs operating at the scale where this makes any
> difference at all have tools to build the DNS forward and reverse entries for
> their infrastructure automatically based on the router name and interface
> name extracted from their inventory tools. It's a few bits of scripting, so it's
> not like having less interfaces in DNS results in any net reduction in work or
> increase in the possibility of mistakes.
> 
> - Draft-ietf-grow-private-ip-sp-cores rightly notes that the proposed
> solution to broken pings/traces/PMTUD from draft-behringer (RFC 5837) has
> little or no implementation. This makes it a hard sell as any sort of
> recommended solution unless the benefits are much more significant than
> what is currently discussed in draft-behringer. This has to be a large enough
> benefit to justify pushing hard on router vendors to implement the feature
> and SPs to certify and deploy the code, and frankly there are many more
> important features to consider.
> 
> Thanks,
> 
> Wes George
> 
> 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of [e-mail]
> > Sent: Wednesday, March 28, 2012 7:21 AM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: [GROW] I-D Action: draft-ietf-grow-private-ip-sp-cores-00.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories. This draft is a work item of the Global Routing
> > Operations Working Group of the IETF.
> >
> >       Title           : Issues with Private IP Addressing in the Internet
> >       Author(s)       : Anthony Kirkham
> >       Filename        : draft-ietf-grow-private-ip-sp-cores-00.txt
> >       Pages           : 15
> >       Date            : 2012-03-28
> >
> >    The purpose of this document is to provide a discussion of the
> >    potential problems of using private, RFC1918, or non-globally-
> >    routable addressing within the core of an SP network.  The discussion
> >    focuses on link addresses and to a small extent loopback addresses.
> >    While many of the issues are well recognised within the ISP
> >    community, there appears to be no document that collectively
> >    describes the issues.
> >
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-grow-private-ip-sp-core
> > s-00.txt
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > This Internet-Draft can be retrieved at:
> > ftp://ftp.ietf.org/internet-drafts/draft-ietf-grow-private-ip-sp-cores
> > -00.txt
> >
> > _______________________________________________
> > GROW mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/grow
> 
> 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.