Jeroen Massar wrote: > 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.
Brian is right, having a second prefix is what they should do. > > > * 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. Using filtering on a single global prefix does not work when nodes that need external access are on the same segment with those that shouldn't have it. Prefix filtering is the answer, but the prefix to filter is FEC0::/10. Tony > > > ----- 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
