-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
>>> 2 Adverse effects of site local addresses
>>>
>>> ==> I showed this draft to a believer of site-local addressing, who
>>> had had
>>> very little experience with IPv6. He was not convinced of the
>>> arguments.
>>> This may be for one of t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On tisdag, sep 23, 2003, at 02:32 Europe/Stockholm, Erik Nordmark wrote:
> I think there is an overarching issue about deployment/transition
> that relates to the NAT thing;
> providing a new service/feature/capability by only adding one box to
> the
On dinsdag, sep 23, 2003, at 07:03 Europe/Amsterdam, Michel Py wrote:
I don't think that the ability to have multiple servers on the same
port
is significant enough to trigger a migration; there would need to be a
more significant change. Bottom line is that on my single IP at home, I
host all th
On Mon, 22 Sep 2003, Brian E Carpenter wrote:
> > 2 Adverse effects of site local addresses
> >
> > ==> I showed this draft to a believer of site-local addressing, who had had
> > very little experience with IPv6. He was not convinced of the arguments.
> > This may be for one of the many re
Erik,
> Erik Nordmark wrote:
> It isn't clear to me at what point the pain caused by NAT in
> different cases will be high enough to motivate a transition
> to some different technology, or whether there must be new
> capabilities (such as the ability to have multiple servers
> at the same port nu
If you continue to be bound by NAT how are you going to connect all the
many many mobile devices to the Internet to exploit the services of
upcoming mobile Internet? Is NAT useful for mobile devices?
-Original Message-
From: Keith Moore [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 23 Septemb
> Is it really true that most of the market chose to use NAT rather than
> tunneling or dual-stack for IPv6 transition mechanism?
there is zero truth to that. if you're going to use NAT there is (almost)
no point in using IPv6.
As a datapoint, it might be worth reading the comments posted to slashdot relating to
this story
End Of the Line for SpeakFreely: NATed to Death
http://slashdot.org/article.pl?sid=03/09/20/1556253&mode=thread&tid=126&tid=185&tid=95
(And yes, I got sucked into it, and ended up looking like I'd j
Hello,
Is it really true that most of the market chose to use NAT rather than
tunneling or dual-stack for IPv6 transition mechanism?
As far as I know, many providers in Japan have long been servicing IPv6
service, and their choice was never NAT. It was mostly tunneling, with
small number of dual-s
> From my SF-centric Nexus-of-the-web-trendiod
> standpoint: for residential use (especially with
> broadband) it is simply impossible to have an
> argument about the evils of NAT.
that's the stupidest thing that's been said here in a long time.
NATs are at least as harmful in a residential envi
Erik Nordmark writes:
> And NATs are used as a technology as part of providing different
> user visible capabilities such as
> - "connection sharing" from home
>From my SF-centric Nexus-of-the-web-trendiod
standpoint: for residential use (especially with
broadband) it is simply impossible to
Pekka,
I think there is an overarching issue about deployment/transition
that relates to the NAT thing;
providing a new service/feature/capability by only adding one box to
the network is a lot easier sell than for instance
- requring a box in the peer's network
- requring all the routers in t
Pekka,
The document came out of the IAB, while the NAT WG was active, so there was a
lot of diplomacy between the IAB, the IESG, and the NAT WG chairs, to get to
a version of the document that everybody was happy with. Since we don't have
a NAT WG today, that side of it might be easier, but it can
Pekka,
Thanks for the review.
Pekka Savola wrote:
>
> Hi,
>
> A couple of comments on deprecate-site-local draft. In general, I think
> the doc is very good, but could use a bit boosting in a couple of areas
> (which -00 draft wouldn't.. :-)
>
> substantial
> ---
>
> Although the con
My feeling is that Pekka is correct. Experience shows that whatever
words we write in RFCs, prefixes leak. But it does seem reasonable to be
clear that FEC0::/10 should be blocked at every administrative boundary.
Brian
Pekka Savola wrote:
>
> On Fri, 19 Sep 2003, Pekka Savola wrote:
> > On T
15 matches
Mail list logo
