Subject: [v6ops] new draft: draft-liu-v6ops-ula-usage-analysis

From: <[email-masked]>
Date: Sat, 22 Oct 2011 06:55:00 -0700 (PDT)

A new draft has been posted, at http://tools.ietf.org/html/draft-liu-v6ops-ula-usage-analysis. Please take a look at it and comment.

---

From: "George, Wes" <[email-masked]>
Date: Fri, 28 Oct 2011 08:20:05 -0400

I support this concept being discussed in v6ops, starting with Taipei if there is room on the agenda. This draft is in pretty rough form, but it'll serve as a good a framework as any to start the discussion.

By way of some background:
Within the context of 6renum, the question came up as to whether we needed to care about ULA and renumbering, and I suggested that there are probably several valid use cases where use of ULA removes or reduces the need for renumbering by eliminating dependency on PI or PA addresses (which are subject to change), and thus should be mentioned. Fred rightly pointed out that it doesn't fix the cases where the admins decide to renumber the internal addresses, it merely makes it so that it might be possible to not renumber hosts that are not using external PI/PA addresses at the time when those need to be changed.

However, I also suggested that there was a lack of clarity around when ULAs are generally appropriate to use vs not, especially if you are looking at this from the (inaccurate) IPv4-centric perspective of ULA being a rough replacement for RFC1918 to give you security by obscurity (and drive the need for NAT66 or some sort of gateway for ULA hosts to access the public internet). What I don't want to see is people interpreting a corner-case recommendation to use ULA within 6renum as a general recommendation that ULA should be used in most enterprise networks, whether to avoid renumbering or otherwise. Recommended and not recommended (considered harmful?) uses/use cases of ULA is something of a gap today, and is by no means limited to 6renum - I think you have similar issues within homenet, the smart grid, internet of things, manufacturing nets, car networks, etc - I know we've had similar discussions on 6man regarding car networks not too long ago, specifically around the "no, really, this is a private network and always will be..." mentality, as well as renewed discussion about some sort of registry to *ensure* global uniqueness for ULA in some applications, so I think that this is necessary work. Likely controversial given its potential impact, but necessary nonetheless.

That said, in reviewing this draft, I take exception with the current method, exemplified by the beginning of section 3 "...we try to cover every possible ULA use case." I don't expect that we'll end up with an exhaustive list of approved and not approved applications/use cases, because that'll be neverending and always inaccurate/incomplete. I envision more of a framework of questions/applications that network admins and designers can use to evaluate the appropriateness of ULA for their application, along with perhaps some explicit recommendations of when ULA is definitely *not* the right choice.

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of [email-masked]
> Sent: Saturday, October 22, 2011 9:55 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [v6ops] new draft: draft-liu-v6ops-ula-usage-analysis
>
>
> A new draft has been posted, at http://tools.ietf.org/html/draft-liu-
> v6ops-ula-usage-analysis. Please take a look at it and comment.
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

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: "Leo Liu(bing)" <[email-masked]>
Date: Sat, 29 Oct 2011 09:57:01 +0000

Hi, Wes

Thank you for the comments. 
I agree with you that this document should give some explicit recommendations rather than an exhaustive list of ULA use cases. 
So far we haven't made any recommendation or conclusion in the initial draft. I think the discussion in WG is necessary and would help a lot if we can achieve some consensus.

B.R.
Bing 

> 
> That said, in reviewing this draft, I take exception with the current method,
> exemplified by the beginning of section 3 "...we try to cover every possible ULA
> use case." I don't expect that we'll end up with an exhaustive list of approved
> and not approved applications/use cases, because that'll be neverending and
> always inaccurate/incomplete. I envision more of a framework of
> questions/applications that network admins and designers can use to evaluate
> the appropriateness of ULA for their application, along with perhaps some
> explicit recommendations of when ULA is definitely *not* the right choice.
> 
> Thanks,
> 
> Wes George
>

---

From: Sheng Jiang <[email-masked]>
Date: Mon, 31 Oct 2011 03:10:03 +0000

We do have some technical preference while we think they need supports from a comprehensive analysis over most, if not all, potential ULA user cases. Overall, our motivation is to change the current situation that ULA is lack of using.

Best regards,

Sheng

> Of Leo Liu(bing)
> Sent: Saturday, October 29, 2011 5:57 PM
> To: George, Wes; [email-masked]
> Subject: Re: [v6ops] new draft: draft-liu-v6ops-ula-usage-analysis
> 
> Hi, Wes
> 
> I agree with you that this document should give some explicit
> recommendations rather than an exhaustive list of ULA use cases.
> So far we haven't made any recommendation or conclusion in the initial
> draft. I think the discussion in WG is necessary and would help a lot
> if we can achieve some consensus.
> 
> B.R.
> Bing
> 
> >