Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)

[Daniel Senie]

At 09:13 AM 10/2/2007, Iljitsch van Beijnum wrote:



On 2-okt-2007, at 15:05, Adrian Chadd wrote:


Please explain how you plan on getting rid of those protocol-aware
plugins
when IPv6 is widely deployed in environments with -stateful
firewalls-.


You just open up a hole in the firewall where appropriate.


It might help if you understood why deep packet inspection firewalls 
exist. If it were as easy as opening holes and trusting hosts, Cisco 
would not have a market for its PIX/ASA products, SonicWALL wouldn't 
exist, Juniper wouldn't have bought NetScreen, and so forth. The 
reality is end hosts are not sufficiently secure. Network security is 
built in layers. Sure, you use whatever you can in the hosts, but you 
don't trust it.


Microsoft has had some spectacular holes that impacted even 
uninfected hosts (by DDoS) such as CodeRed. And this isn't a knock on 
Microsoft. There've been security issues with most systems at one 
point or another. Trusting end systems is insufficient.


Site security policies are often far more complex than can be 
addressed by the servers to be protected, and involve VPN access, 
time-of-day rulesets, attack signature analysis and the like.




You can have an ALG, the application or the OS do this. As you
probably know by now, I don't favor the ALG approach.


That's great that you don't favor it, but firewalls with stateful 
inspection can and do look deep into packets to figure out if the 
packets are legitimate. These devices sell, because they help. This, 
like NAT, is something that came about because of need. IPv6 does not 
remove the need for firewalls. Arguably because of the volume of 
relatively untested software involved on the hosts, firewalls will be 
quite important.




End-to-end-ness is and has been "busted" in the corporate world AFAICT
for a number of years. IPv6 "people" seem to think that simply
providing
globally unique addressing to all endpoints will remove NAT and all
associated trouble. Guess what - it probably won't.


If you don't want end-to-end, be a man (or woman) and use a proxy.
Don't tell the applications they they are connected to the rest of
the world and then pull the rug from under them. This works in IPv4
today but don't expect this to carry over to IPv6. At least not
without a long, bloody fight.


So I'm sure you've explained to the firewall vendors they should be 
selling proxy boxes instead, and they've listened to you. Sorry the 
market has dictated solutions you don't like. Time to move on, and 
stop fighting a battle that's been lost. 

Re: Creating demand for IPv6

[William Herrin]

On 10/2/07, Brian Raaen <[EMAIL PROTECTED]> wrote:
> Actually, a
> better way to push IPv6 is make users want it and feel like they are missing
> out if they don't have it.  I campaign with some kind of slogan like 'got
> IPv6' or "I've got ultra high tech IPv6 for my internet and you don't" with a
> web url like www.getipv6.com (oops, some domain squatter already registered
> it).

Brian,

I offer you two words: Ford Edsel.

It doesn't matter how clever you make the marketing campaign if on
finding out what the product actually is the customers decide they
don't want it.


> This all boils down to simple economics supply and demand.

As far as I can tell, IPv6 is at least theoretically capable of
offering exactly two things that IPv4 does not offer and can't easily
be made to offer:

1. More addresses.
2. Provider independent addresses

At the customer level, #1 has been thoroughly mitigated by NAT,
eliminating demand. Indeed, the lack of IPv6 NAT creates a negative
demand: folks used to NAT don't want to give it up.

This community (network operators) has refused to permit #2, even to
the extent that its present in IPv4, eliminating that source of demand
as well.

Regards,
Bill Herrin


-- 
William D. Herrin  [EMAIL PROTECTED]  [EMAIL PROTECTED]
3005 Crane Dr.Web: 
Falls Church, VA 22042-3004

Re: Creating demand for IPv6

[William Herrin]

On 10/2/07, John Curran <[EMAIL PROTECTED]> wrote:
> >At the customer level, #1 has been thoroughly mitigated by NAT,
> >eliminating demand. Indeed, the lack of IPv6 NAT creates a negative
> >demand: folks used to NAT don't want to give it up.
>
> #1 has been partially mitigated by NAT, and perhaps only temporarily.
>
> The last chapter of that book is yet to be written.

John,

I hated NAT when back when it was called "circuit level proxying," and
I still do. Give me a packet filter any day. But that doesn't matter.

What matters is that a huge number of installations have NAT dead
center in their network security policies. Asking them to deploy IPv6
without NAT is asking them to refactor long held security policies as
a -prerequisite- to using IPv6.

And without IPv6 PI for all, asking them to give up NAT is also asking
them to give up the best tool they have to mitigate the cost of
changing ISPs.

Both of those so they can spend lots of time and money deploying a
protocol which offers them what exactly? I hope you see the problem
here.



On 10/2/07, Seth Mattinen <[EMAIL PROTECTED]> wrote:
> Really? As far as I understood it, I still had to pay $500 for end-user
> allocations.

Seth,

You still pay the up-front but you pay only one annual fee. For an end
user (i.e. PI space) that would have been $100 anyway. Where it makes
a difference is for service providers: they pay a lot more than
$100/yr but won't pay any more for the IPv6 addresses.

Given that the SOHO and hobbyist users don't qualify for IPv6 PI
addresses, the fact that its difficult for them to afford those
addresses is moot.

Regards,
Bill Herrin


-- 
William D. Herrin  [EMAIL PROTECTED]  [EMAIL PROTECTED]
3005 Crane Dr.Web: 
Falls Church, VA 22042-3004

Re: Creating demand for IPv6

[William Herrin]

On 10/2/07, Jon Lewis <[EMAIL PROTECTED]> wrote:
> On Tue, 2 Oct 2007, William Herrin wrote:
> > At the customer level, #1 has been thoroughly mitigated by NAT,
> > eliminating demand. Indeed, the lack of IPv6 NAT creates a negative
> > demand: folks used to NAT don't want to give it up.
>
> At the internet access customer level perhaps.  As a hosting provider, try
> telling your customers "here's your IPv4 /32.  If you need more IPs, just
> use NAT." and see how many customers you retain.

Jon,

Let me spin you a tale. More of a nightmare really.

During early phase of free pool exhaustion, when you can't deliver
more IPv4 addresses to your customers you lose the customer to a
hosting provider who still has addresses left. So sorry. Those will be
some nasty years. Unless you're Cogent, Level3 or one of the others
sitting pretty on a /8. They'll be in phat city.

What should you do about it? Buy stock.

And make no mistake: it will drag on and on. Even when everybody is
well and truly out, there are a heck of a lot of addresses that can be
reclaimed in dialup pools, residential DSL pools and other uses
retroactively deemed wasteful by converting them to NAT. And with NAT
inbound you can load a lot of functions on a single IP address.

How long will it drag on? I'm not that great an oracle. But let me
offer you a mild heresy: when you combine aggressive CIDR with double
and triple NAT do you really believe that 4B addresses can't be enough
for the pushing 7B people on Earth? Must it ever truly end?

IPv4 forever. One possible price for failing to deliver an IPv6 that
customers want today.

Regards,
Bill Herrin



-- 
William D. Herrin  [EMAIL PROTECTED]  [EMAIL PROTECTED]
3005 Crane Dr.Web: 
Falls Church, VA 22042-3004

Rudimentary IPv6 Progress Report Page

[Mike Leber]

I've been messing around with parsing MRT format IPv6 BGP tables and saw
Randy's posts about deployment progress (or lack thereof), so I threw
together this site:

http://bgp.he.net/ipv6-progress-report.cgi

It gives a rough estimate of the percentage of:

* Networks that run IPv6 (currently 3%).

* IPv6 reverse DNS servers that are reachable via IPv6 (currently 31.6%,
believe it or not, most are only reachable via IPv4).  If you have IPv6
reverse DNS servers, do they have an  record for themselves?

* ISPs on the ipv6tf.org ISP list with IPv6 websites (currently 32.2%).
(I'll be the first to admit that Hurricane has a bunch of sites that need
to be fixed to work with IPv6, we just added an  record for bgp.he.net
before posting this.)

* Alexa 500 websites that are IPv6 enabled (currently 0%).

The site is a work in progress.  Feel free to send me suggestions.

Mike.

+- H U R R I C A N E - E L E C T R I C -+
| Mike Leber Wholesale IPv4 and IPv6 Transit   510 580 4100 |
| Hurricane Electric Web Hosting  Colocation AS6939 |
| [EMAIL PROTECTED]   http://he.net |
+---+

Re: Creating demand for IPv6

[William Herrin]

On 10/2/07, Randy Bush <[EMAIL PROTECTED]> wrote:
> > During early phase of free pool exhaustion, when you can't deliver
> > more IPv4 addresses to your customers you lose the customer to a
> > hosting provider who still has addresses left. So sorry. Those will be
> > some nasty years. Unless you're Cogent, Level3 or one of the others
> > sitting pretty on a /8. They'll be in phat city.
>
> this is a very real and significant problem.  a very small fraction of
> the arin membership holds the vast majority of the address space.  it
> would be interesting to ask arin to give us the cdf of this.

Randy,

It would be nice if it was that simple. Those /8's arise from legacy
assignments that fall more or less directly under IANA without any
form of agreement in place that could allow policy change. Barring
government action, they're effectively the unrecoverable property of
those organizations. They can even act as mini-registries and auction
addresses off to the highest bidder if they're so inclined.


> given that, the scenario you present is likely to be very real.
>
> but what do we do about it?

Unless something brilliant arrives out of left field, the only thing
we can do is deploy and get customers to deploy IPv6 -before- IPv4
free pool exhaustion starts to hit. That's really not on track right
now.

Some things which might help get it back on track are:

1. End the insanity of having software prefer IPv6 if available (
records over A records). That's a commonly cited reason that folks who
tried IPv6 stopped using it. I might  make some of my stuff available
via 6to4 but 6to4 is pretty meager so there's no way I'd consider it
when stacks will prefer trying to communicate with IPv6.

2. Figure out a PI solution for IPv6 capable of scaling to the
equivalent of hundreds of millions of routes in the core at a
per-route cost two orders of magnitude less than it is today. RRG is
working on this but there aren't enough people involved, they're not
focused on a solution that delivers that degree of scalability,
they're not in a hurry and AFAIK they're not well funded. This seems
self-defeating given how much money rides on a useful answer coming
out of the IETF.

3. Produce IPv6 NAT. Folks are used to NAT. They're comfortable with
the security they believe NAT provides. They might eventually switch
away from NAT if some desirable new application requires it but they
won't refactor their network security policies as a prerequisite to
deploying IPv6.


On 10/2/07, Mark Smith
<[EMAIL PROTECTED]> wrote:
> Have you used a NAT free Internet?

Mark,

I maintain a /23 in the swamp and have since '94. For the record, I
didn't even like NAT back when it was still called "circuit level
proxying."

I'd love to have an Internet where all firewalls were packet filters.
But that's not my call. That's the call of hundreds of thousands of
network security officers who have NAT written in stone at the core of
their security process. Tying NAT's abandonment to IPv6's deployment
won't change their minds but it will doom IPv6.


> So if more addresses was "thoroughly mitigated by NAT", when were these
> problems that NAT creates fixed?
> http://www.cs.utk.edu/~moore/what-nats-break.html

Many of those never were meaningful problems and most of the rest have
been obsoleted by the changing reality of network security on the
Internet. Things like controlling the source port meant something once
upon a time, but they have no place in a modern security
infrastructure. That would be true with or without NAT.

The -real- problems with NAT can be summed up in two statements:

1. NAT makes it more difficult to engage in certain popular activities
that strictly speaking are against the TOS.

2. NAT makes logging and accountability more difficult.

Regards,
Bill Herrin



-- 
William D. Herrin  [EMAIL PROTECTED]  [EMAIL PROTECTED]
3005 Crane Dr.Web: 
Falls Church, VA 22042-3004