Re: More comments on draft-palet-v6ops-proto41-nat-00.txt

[Carlos Friacas <cfriacas@fccn.pt>]

Hello.
Again, inline.


> > I have some questions:
> >
> >
> > [1, Introduction]
> >
> > + "routers or tunnel servers" ~= "tunnel brokers" ?
> >
> >   "(...) with a manual configuration at the IPv6 router tunnel-end."
> >   It isnt feasible for a service you intend to sell. using manual
> >   configurations on routers simply isnt scalable.
>
> I'm not implementing a service just describing an option to do it.
> Is a decision of the implementor how it should be.

Perhaps you should make a reference in your document, that this approach
will lead to manual configurations. It would be nice to have this explicit
-- you are documenting "testbed procedures".



> > + reference to [3]
> >
> >   I still dont understand why a project focused on
> >   Internet Exchanges (IXPs/NAPs/...) may have anything to do with NAT
> >   boxes and tunnels. End-users shouldnt be a topic. People managing
> >   networks, BGP and AS numbers should.
>
> Well, I guess you shouldn't try to tell the "inventor" and technical
> responsible of a project what's the project scope.

I've read the documents publicly available at the project's site.
That was the reason i did the comment in the first place.



> I can tell you that Euro6IX scope is not ONLY the IXs, but also how they
> become useful to users,

IXs are interconnection points. They have a central role in avoiding
traffic from ISP A to ISP B in city X, from going to city Y.
IXs' issues are lower latency, redundancy, etc... in the end, they will
benefit users, but final users *DONT* connect to IXs.

Your projects' credibility would be significant if AMS-IX, LINX, DECIX and
others (real IXs) were a part of the project...



> and whatever is needed to foster the
> deployment of IPv6.

I can concurr with that. IPv6 deployment (and widespread) depends also
on the capability of ISPs connecting natively to their local IX (and
transit providers connecting to several IXs).



> This information is explained in the project
> documents, publicly available.

Yes, i've seen those.



> > + "big opportunity to rapidly deploy a huge number of nodes and networks"
> >
> >   You mean, nodes of tunnel brokers?
> >   networks? ...using a router as a NAT client? it may seem as a good "hack
> >   idea" to use a laptop for this.
> >   a theoretical question -- does the community want rapid deployment? with
> >   high RTTs and high chance of self-denial-of-service ?
> >   ...or is it a way to kill IPv6 faster?
> >
>
> I think the text is clear on this point, and again I don't need to consider
> how to implement the service, just offer a solution to deploy it.

What i was trying to query, is your opinion on this being a *bad*
solution or not (considering the roundtrip, complexity, etc...).
In any case, huge number of nodes/networks connected to
tunnel brokers (in reality they are only a few...) should be documented
as a poor solution.



> > + last paragraph
> >
> >   You are listing the need to:
> >   - change tunnel brokers
> >   - change something in some operating systems (which ones?)
> >   Wouldnt be easier to v6-ize the NAT boxes? (dont know if it would be a
> >   good idea, as we dont need NAT boxes in the native IPv6 world...)
> >
>
> I'm not specifying the tunnel brokers, and thus no need to indicate what scripts for what OS should be changed. This will be another
> document.

Its some sort of???: "I think IP will run better with 512 bits addresses
-- hey everyone: change all your applications to meet my view!"
I would wish to know more about what is needed on the tunnel brokers
end...



> No, not all the vendors are going to make the effort and investment in
> provide native IPv6, and not all the existing hardware
> supports it.

If they dont provide, customers will simply prefer other vendors...



> > [4, Applicability]
> >
> > + "The most usual scope of application of this technology seems to be
> >    SOHO and home environments, but is not limited to these."
> >   Do you mind to specify more environments? I think it would be important
> >   to specify, if they exist.
>
> Whatever where there is a NAT box ;-)

So: "SOHO and Home".
Where can we think about using a NAT box with an environment that you can
name differently??? anyone?



> > [5, NAT design considerations]
> >
> > + "New firmware/software versions of the NAT implementations should
> >    ensure the support of protocol-41 forwarding."
> >
> >   I would add: ", and the means for its administrator to turn it on and
> >   off".
> >   As an example, we wouldnt want anyone using a connection to a tunnel
> >   broker if native IPv6 is available on the wire/air.
> >   Mandatory support for protocol-41 forwarding seems unnappropriate, as
> >   tunnels usage will fade away (as a method of getting IPv6 connectivity).
> >
>
> The only one that have access to the NAT boxes is the administrator
> (in most of the scenarios the owner/user = SOHO).

changing this draft to "informational" was good.



Regards,

./Carlos                                                "Networking is fun!"
--------------         [http://www.ip6.fccn.pt]           http://www.fccn.pt
<cfriacas@fccn.pt>, CMF8-RIPE, CF596-ARIN, Wide Area Network Workgroup
F.C.C.N. - Fundacao para a Computacao Cientifica Nacional fax:+351 218472167
                [ See me @ h323:videoconf05.fccn.pt]
  "Internet is just routes (125953/461), naming (millions) and... people!"