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

[Anthony Kirkham <[e-mail]>]

Tom,

Thank you for your update and support. I will incorporate your earlier 
comments in the next week or so.

Also, thanks to Wes George for his review and comments.

Personally, I'd like to see the draft get approved and published as an 
RFC. From various peoples comments to me, I understand the draft as it 
stands contains some information useful to the industry, particularly at 
this point in time. I don't believe there are any areas of dissent.

I do note that there have been some good ideas for improvement, in 
particular from Bruno Decraene (to incorporate a more in depth analysis 
of stolen IPs), and also the suggestion to include the equivalent 
analysis for IPv6 LLA. These are good ideas, however, will they will 
take more time to progress. My suggestion would be to perform these as 
follow on activities. I hope this makes sense.

Regards
Tony K





On 31/03/12 8:26 PM, t.petch wrote:
> ----- Original Message -----
> From: "George, Wes"<[e-mail]>
> To:<[e-mail]>;<[e-mail]>
> Cc:<[e-mail]>
> Sent: Saturday, March 31, 2012 1:14 AM
>> 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.
> <tp>
> Disagree.  As you say, the grow draft is more or less complete, more or less
> ready for WGLC.  And it has taken the IETF two years to get to this state.
>
> IPv6 is different.  We probably know little as yet as to how it works or how it
> should.
>
> Adding IPv6 would put this work back a year or two, and given that GROW is not
> the most lively of growps, it may never happen.
>
> Get the grow draft out as an RFC while it is still of value to its audience.
>
> Then contemplate a -bis with IPv6 if there is sufficient enthusiasm in a WG to
> do so.
>
> Tom Petch
>
>
>
>
>
>
>> 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-cores-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.
>> _______________________________________________
>> GROW mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/grow
>>
>>
> _______________________________________________
> GROW mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/grow
>
>


--