On Jul 17, 2012, at 8:48 AM, Michael Behringer (mbehring) wrote: > 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.
Excellent (actually, I believe that draft-ietf-grow-private-ip-sp-cores lies with the IESG at the moment, and so it kinda has to stay 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. > Cool. > 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. > Excellent, and just to close the loop (so v6ops / grow folk know), you did ask, and we've created a slot on the OpSec agenda (15min, Wednesday, Aug 1, 13:00 - 15:00, Georgia B) for this... W > Eric and Michael > >> -----Original Message----- >> From: George, Wes [mailto:[email protected]] >> Sent: 31 March 2012 01:15 >> To: [email protected]; [email protected] >> Cc: [email protected]; 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: [email protected] [mailto:[email protected]] On Behalf >>> Of [email protected] >>> Sent: Wednesday, March 28, 2012 7:21 AM >>> To: [email protected] >>> Cc: [email protected] >>> 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 >>> [email protected] >>> 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. > _______________________________________________ > GROW mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/grow > -- "Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life." -- Terry Pratchett _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
