[arin-discuss] Trying to Understand IPV6

[Nathaniel B. Lyon]

We are starting to NAT customers behind our modem/CPE.  We used to be a fully bridged network, and now are handing the IP to the CPE and NAT'ing the customer behind our CPE's.  Much more secure.  That's for sure.  

NAT'ing isn't all evil, but NAT'ing 500 - 1000 customers behind 1 IP isn't the best of ideas.  IMO

-----Original Message-----
From: arin-discuss-bounces at arin.net [mailto:arin-discuss-bounces at arin.net] On Behalf Of Mike Lieberman
Sent: Monday, September 13, 2010 3:52 PM
To: 'Matthew S. Crocker'
Cc: arin-discuss at arin.net
Subject: Re: [arin-discuss] Trying to Understand IPV6

We run VoIP over NAT today and while there is a learning curve it is manageable.

Make a mistake in NAT'ed network and NAT will save you in-spite of yourself. 
Make a mistake in Public IP and you are potentially sunk.

As an advocate for the end user - even when it makes my job harder.... NAT isn't evil. Network Engineers who expect all consumers to be knowledgeable are evil. We need to employ technologies that are safe even when used badly. 
Public addresses on residences fails the test.

It's nice that some of you trust public institutions to always behave and do right. Do I offend you that you are in the aggregate in the extreme minority?

-----Original Message-----
From: Matthew S. Crocker [mailto:matthew at crocker.com]
Sent: Monday, September 13, 2010 2:44 PM
To: Mike Lieberman
Cc: arin-discuss at arin.net
Subject: Re: [arin-discuss] Trying to Understand IPV6



In short because NAT is evil.  Customers don't normally have a clue what NAT means or if it actually provides security or not.  A properly configured home
IPv6 appliance can provide the same levels of security without NAT. Stateful packet inspection and real IPv6 addresses on all devices is far superior to NATted IPv4

NAT is the bane of my existence as a VoIP provider.  If only my phones supported IPv6...

-Matt

----- Original Message -----

> From: "Mike Lieberman" <mike at netwright.net>
> To: arin-discuss at arin.net
> Sent: Monday, September 13, 2010 4:17:37 PM
> Subject: Re: [arin-discuss] Trying to Understand IPV6
>
> I have been reading all these discussions (mostly silently) for a 
> long, long time. I understand what a /48 is and a /56, /64 and /128. I 
> understand the notation.
>
> Quite frankly what I don't get is why anyone thinks that consumers 
> want public numbers inside their home/LANs.  Once my customers 
> understood the benefit of hiding behind a NAT, they embraced it quite 
> emphatically.
>
> Put a private residence on public IPv6? Sorry but that makes no sense.
>
>
> Yes I agree that I don't know what people will need in 20 years. And 
> YES it is nice that we will have address space in 20 years. But 
> allocating a
> /48 to
> a home that today uses an IPv4 /30 with a private NAT seems beyond 
> humorous.
> It just sounds insane. Using private addressing that home already 
> potentially has access thousands of subnets and millions of addresses.
>
>
> RFC 4193 provides even more addresses for use with firewall/NAT 
> appliances.
> Why does a home or business using RFC 4193 need a /48 or even a /56 or 
> /64.
>
> Just because we have the numbers does not mean we should distribute 
> them.
>
>
> _________________________
> Mike Lieberman, President
> Net Wright LLC
> Tel: +1-307-857-4898
> Fax: +1-307-857-4872
>
>
> -----Original Message-----
> From: arin-discuss-bounces at arin.net
> [mailto:arin-discuss-bounces at arin.net]
> On Behalf Of Dan White
> Sent: Monday, September 13, 2010 1:28 PM
> To: Tim Howe
> Cc: arin-discuss at arin.net
> Subject: SPAM: Re: [arin-discuss] Trying to Understand IPV6
>
> On 13/09/10 12:01 -0700, Tim Howe wrote:
> >On Mon, 13 Sep 2010 19:32:33 +0100
> ><michael.dillon at bt.com> wrote:
> >
> >> > If I assigned a customer say an IPV4 /21 in IPV6 this would
> translate
> >> > into a /56? If I'm not mistaken a /56 would translate into
> something
> >> > like 65,000 host addresses? That just seems like a lot of hosts
> to me,
> >>
> >> Anyone in this position should simply assign a /48 to every
> customer site
> >> no matter how big or small. A one bedroom apartment gets a /48. A
> manufacturing
> >> plant with 5 buildings including a 4-story office block, gets a
> /48.
> >> No exceptions.
> >
> >	This is slightly different than I have been led to think...  It 
> >seems wise, when you know the customer has no intention of having 
> >multiple networks, to provide a /64.  Not because you fear wasting
>
> Consider a long range scenario for that customer. A scenario in which 
> they may purchase networking equipment for multiple purposes in 5 or 
> 10, or 20 years that performs layer two separation between different 
> functions in their network. E.g. Wifi, Bluetooth/USB, appliances, 
> voice, video, visitor access, alarm system, automobiles, utilities, 
> etc.
>
> I find it benefitial to consider that I probably don't know what a 
> customer's network will look like in 20 years, and a /48 per customer 
> is probably wisest until we've gained more operational experience with
> IPv6 in
> our own network.
>
> --
> Dan White
> _______________________________________________
> ARIN-Discuss
> You are receiving this message because you are subscribed to the ARIN 
> Discussion Mailing List (ARIN-discuss at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-discuss
> Please contact info at arin.net if you experience any issues.
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date:
> 09/13/10
> 00:35:00
>
> _______________________________________________
> ARIN-Discuss
> You are receiving this message because you are subscribed to the ARIN 
> Discussion Mailing List (ARIN-discuss at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-discuss
> Please contact info at arin.net if you experience any issues.
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.851 / Virus Database: 271.1.1/3128 - Release Date: 09/13/10 00:35:00

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.851 / Virus Database: 271.1.1/3132 - Release Date: 09/13/10 01:35:00