----- Original Message ----- From: "Jeroen Massar" <[EMAIL PROTECTED]> To: "'Brian McGehee'" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, April 02, 2003 4:14 AM Subject: RE: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local Addressing)
> Brian McGehee [mailto:[EMAIL PROTECTED] wrote: > > > *Notes below > > > > * I agree "NAT != SL"! Except in the case that hosts need "global" > > connectivity and they ONLY have a SL address will require > > NAT. Or they should have a second IPv6 globally unique unicast > address > > (which isn't that hard to have multiple addresses???) > > Use a firewall to block incoming packets. > > > * I can envision an enterprise environment that is comfortable using > > FEC0::/10 for internal communications but a host has a globally unique > > address also for external communications (on hosts that have this > > neccessity) This could be comfortable to a network admin/ops/noc. > > Then don't route a certain prefix. Which prefix? SL Prefix? Where is the alternative? > > > ----- Original Message ----- > > From: "Jeroen Massar" <[EMAIL PROTECTED]> > > To: "'Brian McGehee'" <[EMAIL PROTECTED]>; > > <[EMAIL PROTECTED]> > > Sent: Wednesday, April 02, 2003 2:53 AM > > Subject: NAT != SL (Was: RE: CONSENSUS CALL: Deprecating Site-Local > > Addressing) > > > > > > > Brian McGehee write: > > > > > > > NO -- Do not deprecate site-local unicast addressing > > > > > > > > - Site-locals should be retained for disconnected sites. If > > > > not SL, then > > > > a mechanism needs to be adopted that can provide a > > private means of > > > > selecting from a private address space that is "reserved" for this > > > > function. 2002 is not a working alternative. > > > > - Site-locals should be retained for intermittently > > connected sites. > > > > - Site-locals should be retained as a means for internal > > > > connections to > > > > survive global prefix renumbering. > > > > > > All of the above will make the address not unique. > > > Have fun merging your networks. > > > > * Anyone that has had to merge 2 very large networks will > > know the great amount of design, architecture, and planning > > that has to go into such a project. It's not as easy as > > changing "a DHCP range" or a "handful of RAs" even if they > > were Globally unique IPv6 (or globally unique IPv4 addresses). > > I agree that IPv6 stateless Auto-Config adds a lot of room to > > make this an easier process but it doesn't solve the unique > > problems that come up in merging two large enterprise networks. > > If they are globally unique, one doesn't HAVE to renumber. > And indeed the problems of renumbering lie in configuration items > not in the network numbering itself. > > > * Yes. There is the chance that SL will "overlap" in a > > situation of merging two IPv6 enterprise networks. > > But if we don't offer SL. What will people > > choose for private addressing? I would REALLY like to see an > > alternative to SL that maybe provides for a set of bits that > > relate to Geography? ISP? > > etc? I'm open to other suggestions. But without an > > alternative I have to vote "NO". Let's see some alternatives? > > Please, again!=> Let's not alienate those that are already > > afraid of change by "changing" things. > > A central registry where one can obtain unique disconnected > space per /48. > > > > > - Other (please specify). Continually changing the specs > > will only > > > > further alienate those that refuse to adopt. Not offering > > > > equivalents to what exists today (rfc 1918) will > > accomplish the same. > > > > (and do we really want to put all the NAT vendors out of > > business? > > > ;-) > > > > "Necessity drives ingenuity." > > > > > > Here you are already levelling NAT with SL. > > > If you already intend to NAT, stay with IPv4, you will have the same > > > problems and still won't get back the end to end connectivity which > > > was one of the major things IPv6 was built for. Or we could just > > > do IPv6 with 32bits again... > > > > * Yes if anyone chooses to do NAT. They should have that > > option, and an IPv6 address space to appropriately use for > > such functionality [it's a feature, not a bug](some people > > feel strongly that NAT is a security feature). > > If you intend to do it then just stay with IPv4 without > end-to-end connectivity and don't drag down the rest of us. > > > * Again we shouldn't "take away" from what is already there. > > From what people are comfortable with! I am not a proponent > > of NAT (bottlenecking, added administration, etc...) but we > > need to continue to support environments that exists today. > > If a company decides to incorporate NAT in their firewall(s) > > "Look mom he said NAT and firewall in one sentence" > > > (or even NAT-PT/NAPT-PT), well let's let them! We've > > introduced these ideas in IPv4, they exist today. > > They didn't pay with money a very long time ago. > Should we now all go exchange eggs, chicken and wild > beast again as a currency? > > That's called evolution. There is no need for NAT which > is apparently the sole reason you want SL. > > > The current "IPv6 RFC's" and "IPv6 literature" document this > > continued support clearly (FEC0::/10). > > And people have realized that it was a mistake and want to > clear that mistake up before it starts to hurt hard. > > > Constantly changing the standards scares "people" away from > > adoption. Do we really want to make such a drastic change. > > (I'm still trying to deal w/ the deprecation of A6 records. > > They worked GREAT in renumbering!) > > If you have a real use for A6, just like A6, then document > it and bring it forward, thats where these WG's are all about. > > > Yes. IPv6 offers 340 undecillion (or sextillion depending > > on where your from) addresses. Enough to address every > > device in the world. > > Indeed so where did we need SL for again? To NAT???? > > > Great. But we need to offer all the functionality that > > exists today. They exist for reason (besides just lack > > of address space. > > And which reasons where that again, I don't recall you > mentioning ANY reason here that doesn't relate to NAT. > Again, if you want NAT, then stick to IPv4. > > > Some people feel secure/comfortable behind NAT!) > > ...my $.02 > > You should not feel secure behind a NAT. NAT has nothing > to do with security. Not routing a prefix somehow has though. > > Apparently you have no other need for SL than to NAT. > I rest my case. > > Greets, > Jeroen -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
