Re: [renum] Usage of ULA

[Jiangsheng <[e-mail]>]

Fully agree with George. Yes, we need to cover ULA in the enterprise renumbering draft since it is a current practise. But, we don't have to make a judge in 6renum. What is in WG scope is to document: ULA is there, its renumbering can be separated from global prefix renumbering and in which case ULA also needs to be renumbering.

The discussion of general ULA usage should fit in v6ops wg. I (calling contributors here) will write a v6ops draft to analysis this. Of course, reducing the renumbering requirements would be considered, too. If consensus can be reached after analysis and discussion in v6ops, there may be recommendations.

Sheng

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of George, Wesley
> Sent: Thursday, August 11, 2011 11:01 PM
> To: Teco Boot; Brian E Carpenter
> Cc: [e-mail]
> Subject: Re: [renum] Usage of ULA
> 
> Top-posting because I can't find a good place to insert it into the
> thread...
> 
> I think we need to cover ULA, but I don't know if it's really special
> as a renumbering case, and would like to see us discuss (on list) what,
> if any, special treatment it might need when hosts with ULA need to be
> renumbered to determine if it really does need to be treated separately
> or whether we simply note that the techniques will work with ULA just
> like any other global-scope address.
> 
> Then there's the separate question about whether to recommend ULA as a
> way to potentially reduce the cases where renumbering would need to
> take place. I think it's worth discussing, but we probably need to have
> some additional discussion on exactly which cases it would help, and
> the tradeoffs to using ULA to solve that problem. We're not there yet
> based on the current discussion.
> I think part of the problem is that people are conflating possibly
> valid ULA use cases with things like addressing devices with only a ULA
> plus NAT66 or a proxy to limit reachability in order to somewhat
> replicate the behavior of RFC1918 addresses + NAT44 in IPv6. I don't
> believe that the renumbering working group is the right forum to have a
> discussion about whether that's an acceptable idea or a Very Bad Idea
> (tm). I'd say that v6ops would be a better place to author "ULA-only +
> NAT66 considered harmful" or "General recommendations on usage of ULA
> in the enterprise."
> Let's try to focus the discussion on the assumption that there are
> still going to be instances like those defined in RFC1918 (specifically,
> Category 1) in the IPv6 world, perhaps coupled with a small discussion
> in the draft about the likelihood of multiple addresses each with a
> different reachability scope being present on many devices as a matter
> of common practice.
> 
> Thanks,
> 
> Wes
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Teco Boot
> Sent: Wednesday, August 10, 2011 11:41 AM
> To: Brian E Carpenter
> Cc: [e-mail]
> Subject: Re: [renum] Usage of ULA
> 
> +1
> And inline remark.
> 
> Op 9 aug 2011, om 23:27 heeft Brian E Carpenter het volgende geschreven:
> 
> > On 2011-08-10 00:06, Eric Vyncke (evyncke) wrote:
> >
> >> My recommendation against ULA for enterprise is based on several
> existing customers though... This is not a theory :-)
> >
> > I'm fully aware that current enterprise network managers don't find
> this
> > solution compelling. But we are talking about the next thirty years,
> not
> > the previous thirty years.
> >
> > On 2011-08-10 00:14, Eric Vyncke (evyncke) wrote:
> >> Brian and Jiangsheng,
> >>
> >> Together with some colleagues, we have deployed actual IPv6 networks
> in US and EU enterprises (and not only Universities).
> >>
> >> The combination of ULA + PA is simply unnecessary complications (as
> a change of PA requires anyway a renumbering) even if it works on paper.
> (my colleagues and myself were wrong at that point of time as we pushed
> ULA+PA... but this is way too complex).
> 
> 
> >
> > You seem to be ignoring the arguments for this solution. Since I have
> already
> > co-authored an RFC that explains those arguments, I won't repeat
> myself again...
> >
> >> ULA alone requires NPT66 and I daresay that none of us really want
> this :-)
> >
> > Certainly not, although I fully expect to see it sold and deployed.
> Such sites
> > won't need to renumber, so we can ignore them.
> 
> Sites with NPT66 can have a need to renumber.
> Reasons (from RFC 5887 intro):
> 
>    o  Change of site topology (i.e., subnet reorganisation).
> 
>    o  Merger of two site networks into one, or split of one network
> into
>       two or more parts.
> 
> Teco
> 
> 
> >
> >>
> >> Again, the above is for 'normal' enterprises not for residential
> home networks.
> >>
> >> And, by the way, there is nothing about security in ULA... if
> routing information leaks, then your ULA is obviously reachable. Or
> your ULA can send packets to the outside PA space (if anti-
> spoofing/anti-bogons is not applied), welcome to Trojan...
> >>
> >> And, regarding PI, the cost of PI space is paper work (and being
> dual-home) + a couple of 1000 USD/EUR => which is negligible wrt to
> OPEX cost saving (or even CAPEX to buy a NPT66 device).
> >
> > The cost of PI is that it will eventually stretch the BGP4 system
> beyond its scaling
> > limit. See RFC 4984 and RFC 6115 for example. We have a collective
> duty to find
> > an alternative. In fact that's the fundamental reason why this WG
> exists.
> >
> > I think Sheng was right previously. We should treat ULA as a part of
> the landscape,
> > which will be used by some enterprises but not others. A
> recommendation either
> > way is out of scope.
> >
> > In fact the same would apply to PI vs PA. It's mainly orthogonal to
> renumbering.
> >
> > One thing we can't ignore is that a site may be operating multiple
> prefixes
> > Whether they are PI, PA or ULA is secondary.
> >
> >   Brian
> >
> >> -éric
> >>
> >>
> >>> -----Original Message-----
> >>> From: Jiangsheng [mailto:[e-mail]]
> >>> Sent: mardi 9 août 2011 03:52
> >>> To: Eric Vyncke (evyncke); Tim Chown; [e-mail]
> >>> Subject: RE: [renum] Usage of ULA
> >>>
> >>>> - enterprise like, this is a managed network with a fixed PA space
> (or
> >>>> even PI space). Those networks are outside of homenet (my
> understanding
> >>>> at least). I know about NO enterprise using ULA, they all use
> global
> >>>> addresses (except may be in labs).
> >>>>
> >>>> If 6renum focus is on enterprise, then we should clearly say 'ULA
> are
> >>>> NOT recommended'
> >>> I disagree the conclusion here. Yes, ULA is not widely used so far.
> But this
> >>> does not prove ULA is a bad solution. Yes, hosts need global
> addresses; but
> >>> this is IPv6 now, host can have multiple addresses at the same time.
> So, this
> >>> does not prevent hosts have global + ULA. They are used for
> different
> >>> purpose. If the conclusion changed to be "ULA ALONE are NOT
> recommended", I
> >>> am fully agreed. (ULA alone may actually mean host access internet
> through
> >>> NAT66).
> >>>
> >>> Sheng
> >>>
> >>>>> -----Original Message-----
> >>>>> From: [e-mail] [mailto:[e-mail]] On
> >>>> Behalf Of Tim
> >>>>> Chown
> >>>>> Sent: lundi 8 août 2011 15:29
> >>>>> To: [e-mail]
> >>>>> Subject: Re: [renum] Usage of ULA
> >>>>>
> >>>>> Hi Sheng,
> >>>>>
> >>>>> On 8 Aug 2011, at 03:19, Jiangsheng wrote:
> >>>>>
> >>>>>> In the IETF81 meeting, we have some quite different opinion
> >>>> regarding to
> >>>>> whether we should recommend the usage of ULA. Some said it is
> very
> >>>> helpful
> >>>>> for some scenario, particular to link multiple-site enterprise
> >>>> network
> >>>>> together. Some said ULA addresses are dangerous, especially, they
> may
> >>>> be used
> >>>>> like private addresses, therefore requests NAT66 services at the
> exit
> >>>> of
> >>>>> enterprise network.
> >>>>>
> >>>>> I think if our aim is to document current practice, then I
> suspect
> >>>> ULAs are
> >>>>> not widely used at present.  It would be really good to hear from
> any
> >>>>> enterprise (or other) sites that are using them.
> >>>>>
> >>>>>> Authors' catch from the WG, mainly from Tim Chown (wg chair) and
> >>>> Mark
> >>>>> Townsley is: ULA can be recommended, but ULA should not be the
> only
> >>>> IPv6
> >>>>> address on the hosts. If the host is allow to access or be
> reachable
> >>>> by the
> >>>>> internet (outside of enterprise network), the host should have at
> >>>> least a
> >>>>> global IPv6 address besides ULA.
> >>>>>
> >>>>>
> >>>>> Indeed, I would personally assume ULAs are used alongside globals,
> >>>> not alone
> >>>>> with NAT66.  At the enterprise scale, the issue then remains
> >>>> renumbering the
> >>>>> global prefix when required.  If you consider that in your
> enterprise
> >>>> draft
> >>>>> you have cited renumbering triggers that may be externally or
> >>>> internally
> >>>>> driven, renumbering of ULAs may still be required for internal
> >>>> renumbering
> >>>>> purposes (growth, reorganisation, etc).
> >>>>>
> >>>>> There is likely to be some overlap here with homenet, in that
> such
> >>>> networks
> >>>>> will need persistent, stable addressing, with routing potentially
> >>>> between
> >>>>> multiple internal subnets.  Section 4.3 of RFC 6204 talks about
> ULA
> >>>>> requirements for basic IPv6 CPE devices, for example.
> >>>>>
> >>>>> Tim
> >>>>> _______________________________________________
> >>>>> renum mailing list
> >>>>> [e-mail]
> >>>>> https://www.ietf.org/mailman/listinfo/renum
> >>>> _______________________________________________
> >>>> renum mailing list
> >>>> [e-mail]
> >>>> https://www.ietf.org/mailman/listinfo/renum
> >> _______________________________________________
> >> renum mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/renum
> >>
> >
> > _______________________________________________
> > renum mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/renum
> 
> _______________________________________________
> renum mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/renum
> 
> 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.
> _______________________________________________
> renum mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/renum