Subject: RE: (ngtrans) call for discussion on NAT traversial

From: "Christian Huitema" <[email-masked]>
Date: Wed, 18 Jul 2001 08:25:45 -0700

> > I think the aim should be to provide mechanisms to end 
> users AND ISPs 
> > so they can deploy IPv6 over a NAT impaired IPv4 
> network...That would 
> > allow people that do not have IPv4 addresses (and thus use NAT) to 
> > deploy IPv6 and get the benefits.
> 
> There are already mechanisms for this, but more automation (a 
> 6to4 kind of method, instead of static or semi-static tunnels 
> in NATted network) would be nice I suppose.

This is exactly the purpose of the "shipworm" draft: provide automatic
tunnels in a way that will work with most NATs.

---

From: Jim Bound <[email-masked]>
Date: Wed, 18 Jul 2001 14:20:34 -0400 (EDT)

thats fine christian but nat can be avoided in 90% of the cases for IPv6
transition .   

/jim

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Jul 2001 21:26:16 +0300 (EEST)

> thats fine christian but nat can be avoided in 90% of the cases for IPv6

Sure, with (semi)automatic tunneling with private addresses.  It requires
more configuration though, reinventing the wheel N^N times, and cannot be
automated that easily.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Jim Bound <[email-masked]>
Date: Wed, 18 Jul 2001 14:43:20 -0400 (EDT)

I don;t agree it depends how good of a programmer you are this all can be
automated transparent to the user and does require sys mgmt and net mgmt
custom ipv6 boxes.  just this is an opportunity for vendors to build boxes
to support what I am saying in the europe and asian markets even if the
U.S. don't deploy IPv6.  We don't need the u.s. market to begin building
products to make money.  as vendors we have our business case to further
invest engineering of ipv6.  christians draft and idea is just more help
for us to all be interoperable (but I do want to read it 3 times :--)).

the only problem I see is the industry marketing battle now where some
still want to give some credence to the bandaids for ipv4.  I am in the
camp where the ipv4 bandaids are brokend and we believe ipv6 deployment is
mandatory for the Internet to survive and not be replaced as an old
technology.

/jim

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Jul 2001 16:07:44 -0400

>>>>> "Jim" == Jim Bound <[email-masked]> writes:
    Jim> thats fine christian but nat can be avoided in 90% of the cases for
    Jim> IPv6 
    Jim> transition .   

  I just want to be able to do IPv6 from my notebook in a hotel room.
  Christian's draft lets me do *exactly* that.
  
  Once I have a useable IPv6 address, I don't care how many IPv4 NATs 
are in the way.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy");  [

---

From: Pekka Savola <[email-masked]>
Date: Wed, 18 Jul 2001 23:31:06 +0300 (EEST)

> mandatory for the Internet to survive and not be replaced as an old

Another feature of Shipworm, as far as I can see, is that it can be used
even if ISP is indifferent about IPv6; with previous methods, there are no
standardized solutions to traverse NAT -- ISP has to install a box so IPv6
support could work.

One practical requirement in this scenario would be the ability to define
the Shipworm Server, instead of using IPv4 anycast.  As some spoofing
filters might prevent Server from using IPv4 anycast as source, this might
be something to consider anyway, added to the fact that I fear IPv4
anycast isn't really being used much anywhere.

Deployment of _anything_ is really slow.  If you can hack around it, not
requiring the support of ISP, all the better for _you_.

Another question entirely is whether this would courage ISP's to keep
NATting IPv4 and never providing "real" IPv6 service, and as noted,
whether we should keep away from the doomsday beast referred to as NAT (I
fear the current keepalive strategies etc. to deal with different NAT
scenarios will break sooner or later) ...

---

From: Michael Richardson <[email-masked]>
Date: Wed, 18 Jul 2001 17:23:07 -0400

>>>>> "Pekka" == Pekka Savola <[email-masked]> writes:
    Pekka> One practical requirement in this scenario would be the ability to
    Pekka> define the Shipworm Server, instead of using IPv4 anycast.  As
    Pekka> some spoofing filters might prevent Server from using IPv4 anycast

  Yes. I assume this..

    Pekka> Another question entirely is whether this would courage ISP's to
    Pekka> keep NATting IPv4 and never providing "real" IPv6 service, and as
    Pekka> noted, whether we should keep away from the doomsday beast

  well, the places that this would be most useful are the places where my
relationship is the shortest lived, e.g. in hotel rooms, wireless airports, 
non-IETF wireless conferences, etc.

  Often, UDP is not blocked at all, so this lets me freeload :-)
  The hotel now has to deploy something to collect money from me. As long
as they have to deploy, they may well deploy 6to4 support!

    Pekka> referred to as NAT (I fear the current keepalive strategies
    Pekka> etc. to deal with different NAT scenarios will break sooner or
    Pekka> later) ...

  Also, the more state that shipworm takes in the NAT, the sooner the NAT
box falls over. For hotels, this means complaints, which means
refunds. Deploying 6to4 or native IPv6 means going stateless and solving the
problems.

---

From: Keith Moore <[email-masked]>
Date: Wed, 18 Jul 2001 17:53:19 -0400

> refunds. Deploying 6to4 or native IPv6 means going stateless and solving the

given a choice between large numbers of refunds and blocking IPv6, which
do you think the hotel will choose?

maybe we need to convince the folks who make the hotel network systems
to start building 6to4 into their boxes.  (but they still need to
assign at least a /64 to each hotel room :)

Keith

---

From: Michael Richardson <[email-masked]>
Date: Sun, 22 Jul 2001 17:34:22 -0400

>>>>> "Keith" == Keith Moore <[email-masked]> writes:

    Keith> given a choice between large numbers of refunds and blocking IPv6, which
    Keith> do you think the hotel will choose?

  Blocking UDP will not work in this situation.

    Keith> maybe we need to convince the folks who make the hotel network systems
    Keith> to start building 6to4 into their boxes.  (but they still need to
    Keith> assign at least a /64 to each hotel room :)

  Yup.