Re: proto-41 forwarding vs NAT traversal [Re: Tunneling scenarios and mechanisms evaluation]

[Pekka Savola <pekkas@netcore.fi>]

To summarize the inline discussion:

 - counting on NAT boxes implementing v6 and getting those boxes in 
the field would probably require an IPv6 killer application, and IMHO 
we shouldn't be counting on it

 - I don't yet know how to integrate "v6 support in the gateway" in 
the document (somehow in the matrix, vs elsewhere).  If you have 
specific suggestions, fire away.

 - I think it'd be very useful to publish as much info on proto-41
capable (or incapable) boxes as possible; I think that would help us a
lot.  (The same applies to different NAT types wrt. Teredo, but that's
already being done in a separate draft.)

More detail inline..

On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote:
> > On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote:
> > > > True enough.  However, I have doubts on how useful this case is in 
> > > > practice, as a large number of gateways cannot be expected to be 
> > > > upgraded -- that is, we will have to support host-centric deployment 
> > > > in any case.
> > > 
> > > I don't agree. In general is in the other way around. Is more and
> > > more often that the routers, gateways, etc., are updated from time
> > > to time, with new firmware or software.
> > 
> > For technical users, yes; for non-techies, I have serious doubts about
> > that.  DSL products bought or provided by the ISP stay there for 3-5
> > years at least, and they don't have a software upgrade; even if they
> > had, the average user wouldn't know or dare to install it.
> 
> No, I don't think so. More and more users keep updating their
> equipment, even when non-techies. But definitively, no longer the
> equipment is there for so long time, I will say less than 2 years,
> actually.

Let's just say that we disagree on this.

> > If an IPv6 product (e.g., Microsoft's some new shiny new patch kit to
> > use v6 in peer-to-peer) was being deployed, saying "upgrade your NAT
> > box" is not an option.  The case where we can't do anything about the
> > deployed base is the minimal target: it must be supported as well as
> > it can be.  If we can, we might also want to create optimization(s)  
> > for the cases where some box has been upgraded (or not).
> 
> If a wide spread game or product is in the market and requires the
> user to upgrade their box, even purchase a new one to play that
> game, you can make sure that they will do so ;-) The only problem
> right now is the price for IPv6 enabled routers. Hopefully low cost
> models will come soon from Taiwan and China.

Certainly.  But you're counting on a killer application to appear, 
which would make the user to justify investing into a new NAT box, as 
well as spending time on working on a solution.

None have appeared yet, so I do not want us to base IPv6 connectivity
mechanisms on that premise.  These should work (or at least a subset 
of them), even if the killer app doesn't turn up which would make the 
users want IPv6 so bad that they would be willing to buy new hardware, 
require IPv6 from their ISP, etc.

Then we would be where we want to be, of course, but we shouldn't 
count on that.

> > The real market situation can be handled if we design solutions that
> > work with the lowest common denominator (e.g., no NAT/gateway
> > support), right?
> 
> Yes, but choosing only 1 or 2 options (is just an example, I'm not
> counting the real situation right now) may be not optimal, specially
> if we have a 3rd one that could be more optimal in, let's say more
> than 30-40% (may be even less percentage is acceptable) of the
> cases. If that's the case, then we should include that option in our
> matrix.

I think this depends on the complexity of the solution and how big an
optimization it would actually offer.

Currently, the case where NAT gateway implements v6 (like 6to4) does
not seem useful enough, but might become so in the future (and it 
might not hurt to consider how the transition landscape could change 
if that happens).  So, I certainly think it should be mentioned in the 
document, but I'm not yet sure how.  Being included in the matrix 
could be an overkill and difficult, but leaving it out might cause us 
to omit some mechansims (or requirements) which would would be useful 
in the scenario.

So, I'm open to more specific suggestions (than just "include it in
the matrix").  Include it how?  Reword the scenarios how?  I'll 
probably try to think of some means myself, but if folks feel this is 
an important issue, feel free to help... :-)

> > I think it's OK to mention brands and models -- there's precedent in 
> > draft-jennings-midcom-stun-results-00.txt and a lot of other 
> > documents.  We might not want to publish those results as an RFC, but 
> > I think it would be useful to make that list public so folks could see 
> > if they something to add to the list, see whether they have different 
> > experiences, see if their product would be supported or not, etc.
> 
> Ok, then as I can remember, we have all the Cisco, 3Com, Linksys,
> Nokia, D-Link, NetGear, Draytek, SMC, Conceptronic, Allied-Telesyn,
> Develcon, Perle, Trinexus, Yamaha, Zyxel, NEC and Buffalo.
> 
> In addition, looking into the "firmware" of these products, I found
> as a common denominator that they work if they have IOS, VxWorks,
> QnX, Linux, USSoftware, and BSD. Some times the OS is hidden, but
> I've been able to discover it or checking with the manufacturer or
> some document around.
>
> Note that I've not tried all those (may be about 40% of them only),
> but we asked in this list and several others, the people to try out
> and this is the result of the feedback received.
> 
> The only one that I've found myself that failed to support
> proto-41-forwarding was Efficient Networks (I believe now belongs to
> Siemens).
> 
> If you look into the market sharing, I'm very convinced that this is
> even higher than 85%, but just to be conservative ...

Market share is probably an important consideration, but not the only 
one.

Could you get this written up in some form (e.g., a web page,
internet-draft, etc.) with as much detail as possible (and when in
doubt about the information, with contact info etc.).

This would probably make it much easier for folks to see how the 
support SHOULD be and state if there are inaccuracies, start to use 
this if they didn't know their own NAT even supported this, etc.

It may also be worth noting which features are supported.  I recall
there was some confusion wrt. being able to configure an internal host
to receive proto-41 packets (or requiring any other configuration) vs.  
the NAT box working automatically out of the box, or whether it
requires some configuration [what kind of config?] (the out of the box
operation is a very important consideration here).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings