[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More comments on draft-palet-v6ops-proto41-nat-00.txt
Carlos,
My comments in-line.
Regards,
Jordi
----- Original Message -----
From: "Carlos Friacas" <cfriacas@fccn.pt>
To: <v6ops@ops.ietf.org>
Sent: Monday, July 14, 2003 12:09 PM
Subject: More comments on draft-palet-v6ops-proto41-nat-00.txt
>
> Hello All,
>
> 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.
>
> + 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 can tell
you that Euro6IX scope is not ONLY the IXs, but also how they become useful to users, and whatever is needed to foster the
deployment of IPv6. This information is explained in the project documents, publicly available.
>
> + "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.
> + 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.
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.
>
> [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 ;-)
>
>
> [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).
>
> [7, Security]
>
> + (more)
>
> The mechanism of forwarding protocol 41 might be considered a serious
> security issue in some organizations. Those wanting to restrict access
> to some applications/networks for instance. They can/do provide IPv4
> and native IPv6, but with a well-defined set of filtering rules. Using
> (standardizing) a mecanism that permits clients to override the set of
> rules seems dangerous. If vendors start(or continue) to permit
> forwarding of protocol 41 in their factory defaults (expressely or
> somewhat hidden) ops people can have a new plague to toy around, when
> native (and filtered) IPv6 is in place.
>
Exactly the same security issues as you already have with any kind of tunnels. So, the mechanism to override the rules are already
here: Any kind of tunnel of VPN.
The question of what kind of filters or firewalls or whatever is deployed in IPv6 networks, isn't the scope of this document.
>
>
> 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!"
>
*****************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on-line at:
http://www.ipv6-es.com