Re: myth of the great transition (was US Defense Departmentformally adopts IPv6)

[Harald Tveit Alvestrand]

--On tirsdag, juni 17, 2003 11:52:45 +0100 Tim Chown <[EMAIL PROTECTED]> 
wrote:

Fair point.  But a year ago we didn't have Abilene, GEANT or a large
number of European NRENs offering a native IPv6 service.  Cisco and
Juniper's  support has come on in leaps and bounds, and now we do see US
and European real deployment, overlaid on the production IPv4 network,
and we see dual-stack transatlantic links.   On the coal face, we can see
real progress.
A year ago we didn't have official IPv6 support in Windows XP.  We didn't
have prototypes from Sony and Panasnic being shown publicly.   We didn't
have a pilot IPv6 deployment project from Microsoft (threedegrees).
Things  are moving on.  Sure, we'll get hype from the marketing people,
but that's  what they're paid to produce :)
And noone's forcing IPv6 on anybody.  If you want to keep running IPv4,
with or without NAT, feel free.
I actually think the last point is important.

I run IPv6 on some of my boxes now - the only part that gives me a headache 
is when someone else is running an IPv6 service that is less reliable than 
their IPv4 service. Experience breeds confidence.
(and my ISP doesn't know or care that I'm doing it. So much for relying on 
the ISPs)

The difference I see between GOSIP and the US DoD announcement is that 
GOSIP was an attempt to bring something into existence by buying it; the US 
DoD IPv6 announcement says that they have evaluated something that exists, 
and found it useful enough to require it to be present "everywhere".

And I find that a *huge* difference.

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Iljitsch van Beijnum]

On woensdag, jun 18, 2003, at 04:33 Europe/Amsterdam, Hallam-Baker, 
Phillip wrote:

I really wish that the IETF had designed a decent NAT box spec rather 
than adopting the ostrich position.
http://www.ietf.org/html.charters/nat-charter.html

Re: full list for moderated list

[Harald Tveit Alvestrand]

--On tirsdag, juni 17, 2003 09:39:17 -0600 Vernon Schryver 
<[EMAIL PROTECTED]> wrote:

I've not noticed any real opposition to at least open archiving of
moderation rejections.  Is there anything that needs to be done to
make this an official recommendation, IESG policy, or whatever?
IETF mailing list policy is supposed to be grounded in RFC 2418 (WG 
guidelines), RFC 2026 (standard process) and RFC 3005 (IETF list charter).
But these documents are a bit high-level to be useful.

at the moment the only documents of any status that talk about how to run 
IETF mailing lists in any kind of detail are IESG policy documents:

http://www.ietf.org/IESG/STATEMENTS/mail-submit-policy.txt
http://www.ietf.org/IESG/STATEMENTS/moderated-lists.txt
Since the posting of the spamcontrol one (mail-submit-policy), the spam 
problem has grown significantly worse. So it should probably be updated.

And we've had calls for such policy-like things to be more reviewed by the 
community and permanently archived - which usually translates to "RFC 
publication".

It might be a good idea to think about a document or two in this space; I'm 
thinking of:

- IETF mailing list policy: what you should and should not do (BCP)

- IETF mailing list guidance: How to implement the policy using Mailman, 
Majordomo, xxx and  (Info)

A good thing for someone to start writing.?

Re: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Harald Tveit Alvestrand]

Pekka,

why?

I can think of some possible reasons, not necessarily exclusive

- this is a bad idea/impossible to do well, so we shouldn't do it
- some other organization is already doing it, so we shouldn't
- we're too stupid to get it right, so we shouldn't do it
- the IETF is too large, so we shouldn't be adding more work
From your message, I can't tell which of those, or of any number of other 
possible objections, is the basis of your objection.

BTW - all these things were already being worked on in PPVPN. Some were 
even described in the charter.

--On onsdag, juni 18, 2003 09:27:49 +0300 Pekka Savola <[EMAIL PROTECTED]> 
wrote:

Hi,

I do not think this WG should be chartered.

On Tue, 17 Jun 2003, The IESG wrote:
 1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN
   across an IP and an MPLS-enabled IP network, allowing standard
   Ethernet devices communicate with each other as if they were
   connected to a common LAN segment.
I *definitely* think we should *NOT* be working on this.

 2. Virtual Private Wire Service (VPWS)--L2 service that provides L2
   point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI,
   point-to-point Ethernet) across an IP and an MPLS-enabled IP
   network.
We shouldn't be working on this.

 3. IP-only L2 VPNs--L2 service across an IP and an MPLS-enabled
   IP network, allowing standard IP devices to communicate with each
   other as if they were connected to a common LAN segment or a
   point- to-point circuit.
We may have to work on the point-to-point L2 VPN case, but I'd like to
see  alternative approaches to this.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
___
This message was passed through [EMAIL PROTECTED], which
is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on
what to pass are made solely by Raffaele D'Albenzio.

Re: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Pekka Savola]

Hi,

On Wed, 18 Jun 2003, Harald Tveit Alvestrand wrote:
> I can think of some possible reasons, not necessarily exclusive
> 
> - this is a bad idea/impossible to do well, so we shouldn't do it

Yes to both.

> - some other organization is already doing it, so we shouldn't

No idea about that.

> - we're too stupid to get it right, so we shouldn't do it

Yes.

> - the IETF is too large, so we shouldn't be adding more work

Yes.
 
> From your message, I can't tell which of those, or of any number of other 
> possible objections, is the basis of your objection.
> 
> BTW - all these things were already being worked on in PPVPN. Some were 
> even described in the charter.

Fair question, I probably should have included more text in the first 
place :-).

1. Virtual Private LAN Service.  This is Internet-wise ethernet bridging
over routing protocols such as BGP, IS-IS, etc; further, this has
typically little respect for security implications which are implicit (or 
even explicit) in LAN networks.

So, my main points are:

 - we must not overload routing protocols and such infrastructure (IMHO,
this seems an inevitable path the work would go towards..)

 - we must not create complexity by deploying ethernet bridging all over
the Internet.  Our work should be focused on making IP work, not
specifying Ethernet-over-IP (or worse, Ethernet-over-IP as a *service*).

 - it is architecturally wrong: use different subnets, period -- that's 
what those are meant for in the first place!

 - the model has significant security modifications.

Seems like some operators want to move their frame relay (and what have 
you) customers to be bridged over IP, instead of fixing their networks. 
(I'm allowed to say that because I work for an ISP :-).  And vendors are 
desperate to provide to solutions for these "needs".  But is this the 
right approach?  I don't think so.

2. Virtual Private Wire Service

This is slightly better as you're "only" performing point-to-point 
communication.  Same considerations as above apply, to a slightly lesser 
extent.

Btw. how is this different from currently-specified GRE tunneling?  It 
being made a "service"?

3. IP-only L2 VPNs

This seems a subset of case 1), which seems almost reasonable when it's
made for point-to-point links.  I just don't see why folks would really
want anything like this.  I can't figure out *one* area of applicability 
where using layer 3 mechanisms couldn't be made to work around the issue.

> --On onsdag, juni 18, 2003 09:27:49 +0300 Pekka Savola <[EMAIL PROTECTED]> 
> wrote:
> 
> >
> > Hi,
> >
> > I do not think this WG should be chartered.
> >
> > On Tue, 17 Jun 2003, The IESG wrote:
> >>
> >>  1. Virtual Private LAN Service (VPLS)--L2 service that emulates LAN
> >>across an IP and an MPLS-enabled IP network, allowing standard
> >>Ethernet devices communicate with each other as if they were
> >>connected to a common LAN segment.
> >
> > I *definitely* think we should *NOT* be working on this.
> >
> >>  2. Virtual Private Wire Service (VPWS)--L2 service that provides L2
> >>point-to-point connectivity (e.g. Frame Relay DLCI, ATM VPI/VCI,
> >>point-to-point Ethernet) across an IP and an MPLS-enabled IP
> >>network.
> >
> > We shouldn't be working on this.
> >
> >>  3. IP-only L2 VPNs--L2 service across an IP and an MPLS-enabled
> >>IP network, allowing standard IP devices to communicate with each
> >>other as if they were connected to a common LAN segment or a
> >>point- to-point circuit.
> >
> > We may have to work on the point-to-point L2 VPN case, but I'd like to
> > see  alternative approaches to this.
> >
> > --
> > Pekka Savola "You each name yourselves king, yet the
> > Netcore Oykingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >
> >
> > ___
> > This message was passed through [EMAIL PROTECTED], which
> > is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on
> > what to pass are made solely by Raffaele D'Albenzio.
> >
> 
> 

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

Re: full list for moderated list (was: CLOSE ASRG NOW IT HASFAILED)

[Frank Solensky]

On Tue, 2003-06-17 at 07:52, [EMAIL PROTECTED] wrote:
> I think the original idea was better - to only have web archive of those
> posts that did not make it through to the main list...

The downside of this approach, though, is that one would lose the
context in which the discarded message was offered.  OTOH,..

>  If technically easily 
> possible I'd also suggest marking on the main index if post was denied by
> moderator or denied by spam filter.

you'd want to differentiate between the two.

>  And having this archive for only past 
> 3 months seems just fine for that purpose.

The spam, yes.  The other, I'm not so sure -- if someone's making a
charge of unfairness or whatnot, you need to keep that longer.

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Vernon Schryver]

> From: Harald Tveit Alvestrand <[EMAIL PROTECTED]>

> ...
> The difference I see between GOSIP and the US DoD announcement is that 
> GOSIP was an attempt to bring something into existence by buying it; the US 
> DoD IPv6 announcement says that they have evaluated something that exists, 
> and found it useful enough to require it to be present "everywhere".
>
> And I find that a *huge* difference.

At the start of the GOSIP nonsense, that might have been a reasonable
charge.  By the middle, there were at least as many ISO OSI
applications as there are now IPv6 applications, and there was a
lot of real OSI traffic in Europe.  (A "lot" for that era if not
today.)  Major host vendors were supporting OSI protocols by the
end of GOSIP as well as they are now supporting IPv6.  OSI support
was a required checklist item in a lot of sales situations.

The GOSIP history shows that the recent U.S. DOD IPv6 announcement
should neither be overplayed or nor completely ignored.


Vernon Schryver[EMAIL PROTECTED]

RE: myth of the great transition (was US Defense Department formally adopts IPv6)

[Christian Huitema]

> At the start of the GOSIP nonsense, that might have been a reasonable
> charge.  By the middle, there were at least as many ISO OSI
> applications as there are now IPv6 applications, and there was a
> lot of real OSI traffic in Europe.  (A "lot" for that era if not
> today.)  Major host vendors were supporting OSI protocols by the
> end of GOSIP as well as they are now supporting IPv6.  OSI support
> was a required checklist item in a lot of sales situations.

Well, you have to seriously qualify what you call "a lot". The only
non-TCP-IP network service that got widely deployed in Europe was X.25.
Most of its use was not strictly OSI: asynchronous modem connections
according to X.28 and X.29, or enterprise networks using X.25 as a lease
line replacement, much like modern-day VPN. Some of that is still in use
today, e.g. for the French "Minitel" service.

The only OSI service that had significant deployment was the mail
system, X.400. It was used for some research networks, very often
through gateways with SMTP mail. It was also used for exchange of
documents between enterprises in specialized EDI networks.

An aggravating factor in the GOSIP story was the lack of agreement on
the network + transport stack. The US proposed the IP-like CLNP and the
TCP-like TP4, the European X.400 deployments mostly used X.25 and TP0
(null transport), and ECMA was pushing a null network layer combined
with TP4 for European enterprise networks. 

The academics who were using X.400 and experimenting with X.500 quickly
moved to a combination of TCP-IP and TP0 (RFC 987, RFC 1006), because
TCP-IP was more accessible than either X.25 or CLNP. Most X.400 MTA used
in academic networks where dual stack, i.e. able to translate between
X.400 and RFC 822, and most of the traffic moved quickly to plain SMTP.
Similarly, the X.500 experiments resulted in LDAP, i.e. a TCP-IP
application.

Bottom line, there never was a significant usage of CLNP in Europe.

-- Christian Huitema

Re: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Bob Braden]

  *> 
  *> I can think of some possible reasons, not necessarily exclusive
  *> 
  *> - this is a bad idea/impossible to do well, so we shouldn't do it
  *> - some other organization is already doing it, so we shouldn't
  *> - we're too stupid to get it right, so we shouldn't do it
  *> - the IETF is too large, so we shouldn't be adding more work
  *> 

Harald,

Here is one more to consider: maybe it is outside the mainstream of the
Internet architecture.  [Optimizing to leave IP out of the stack and do
direct L2 communication certainly SOUNDS like a retrograde step to me,
too.  Twenty years ago I was arguing with a UCLA professor, who
insisted that IP was too much overhead and that he needed to do direct
LAN transmission to get adequate performance for his distributed file
system.  He eventually figured out the fallacy, because the product
produced by his company had the IP layer in place.  Have we forgotten
these lessons?]

There is an infinite number of variations on the technology that the
IETF COULD develop, and for every one, there is some vendor or set of
vendors who would love to be able to sell sanctioned boxes.  That does
not mean it is in the best interest of the community or the technology
to develop them all.  I believe that the IESG needs to say NO more
often.  I know that's tough, but that's why we chose such excellent
members of the IESG.

Bob Braden

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Keith Moore]

> I really wish that the IETF
> had designed a decent NAT box spec

that's an oxymoron.  the basic premis of NAT is fundamnetally broken.

RE: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Vach Kompella]

Pekka,

>
> On Wed, 18 Jun 2003, Harald Tveit Alvestrand wrote:
> > I can think of some possible reasons, not necessarily exclusive
> >
> > - this is a bad idea/impossible to do well, so we shouldn't do it
>
> Yes to both.

As a meaningless response, I could just say - it's a good idea.  And it is
possible to do well.  That is, of course, as useless as saying it can't be done
well and is a bad idea because it is unsubstantiated.

>
>
> > - we're too stupid to get it right, so we shouldn't do it
>
> Yes.

Speak for yourself :-)

We're doing it.  Hopefully, we're going to get it mostly right if we don't think
that this is a service that scales to infinity.

>
> > - the IETF is too large, so we shouldn't be adding more work
>
> Yes.

So we should not do any new work?!

>
> > From your message, I can't tell which of those, or of any number of other
> > possible objections, is the basis of your objection.
> >
> > BTW - all these things were already being worked on in PPVPN. Some were
> > even described in the charter.
>
> Fair question, I probably should have included more text in the first
> place :-).
>
> 1. Virtual Private LAN Service.  This is Internet-wise ethernet bridging
> over routing protocols such as BGP, IS-IS, etc; further, this has
> typically little respect for security implications which are implicit (or
> even explicit) in LAN networks.
>
> So, my main points are:
>
>  - we must not overload routing protocols and such infrastructure (IMHO,
> this seems an inevitable path the work would go towards..)
>

If you use LDP, it is NOT a routing protocol.  The specific mode of use
(targeted LDP) is already described in RFC 3036.  The FECs are different, but
the FEC TLV was defined in such a way as to be extensible.

>  - we must not create complexity by deploying ethernet bridging all over
> the Internet.  Our work should be focused on making IP work, not
> specifying Ethernet-over-IP (or worse, Ethernet-over-IP as a *service*).
>

Primarily, folks want to use it as in "Ethernet-over-MPLS".  That may not
necessarily go down well with you either, but think of MPLS as a logical FR.
Providers do not want to change their infrastructure, e.g., replace a FR cloud
with an ATM cloud, then with SONET or GigE.  That's mega-expensive.  By
abstracting the L2 using MPLS, they can provide the L2VPN service without
wholesale infrastructure replacement.

>  - it is architecturally wrong: use different subnets, period -- that's
> what those are meant for in the first place!

Use different subnets to create VPNs?  I don't understand what you mean.  VPLS
and VPWS address a requirement for multiple domains (aka VPNs), logically
distinct from and invisible to each other.

>
>  - the model has significant security modifications.
>
> Seems like some operators want to move their frame relay (and what have
> you) customers to be bridged over IP, instead of fixing their networks.
> (I'm allowed to say that because I work for an ISP :-).  And vendors are
> desperate to provide to solutions for these "needs".  But is this the
> right approach?  I don't think so.
>
> 2. Virtual Private Wire Service
>
> This is slightly better as you're "only" performing point-to-point
> communication.  Same considerations as above apply, to a slightly lesser
> extent.
>
> Btw. how is this different from currently-specified GRE tunneling?  It
> being made a "service"?

GRE-tunneling is one option, but only for the transport of the VC.  However, you
need a demux field to identify the VC that you are carrying.  Carrying one
customer VC between a pair of PEs is obviously not adequate.

Tunneling is not new in the IETF.  The fact that you are tunneling what may be
non-IP packets seems to be giving you the heebie-jeebies.  Why?  What about the
tn3270, dlsw, netbios over ip work that has gone on in the past?  A little
massaging to make the packet look like data to be carried over an IP network,
and some implementation details at the edges.

>
> 3. IP-only L2 VPNs
>
> This seems a subset of case 1), which seems almost reasonable when it's
> made for point-to-point links.  I just don't see why folks would really
> want anything like this.  I can't figure out *one* area of applicability
> where using layer 3 mechanisms couldn't be made to work around the issue.

I agree with you on this.  The reason this is there is because some folks want
to do VPLS for IP only, and learn the MACs through the control plane.  I think
once you have VPLS, you don't really need this.

-Vach

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Hallam-Baker, Phillip]

Not at all.

If you want to address denial of service issues you need protocol
enforcement points.

The INTERnet is a bidging architecture between networks. Lets put asside the
dogma and build the infrastucture the users need.

 -Original Message-
From:   Keith Moore
Sent:   Wed Jun 18 09:47:42 2003
To: Hallam-Baker, Phillip
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject:Re: myth of the great transition (was US Defense Department
forma lly adopts IPv6)

> I really wish that the IETF
> had designed a decent NAT box spec

that's an oxymoron.  the basic premis of NAT is fundamnetally broken.

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Keith Moore]

> If you want to address denial of service issues you need protocol
> enforcement points.

NAT is a denial of service attack, not a means of policy enforcement.

Re: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Melinda Shore]

> We're doing it.

That's an "uh-oh" comment.  It's very common to hear people
say that the IETF doesn't know how to say "no" to new work.
I think the real problem is that many people bringing new
work to the IETF don't know how to accept being told "no"
and it leads to harass-a-thons of the IESG on the one hand
and dubious work on the other.  I think part of committing
to working in collaborative organizations like the IETF is
arguing your case the best you can but agreeing to accept
community consensus even if it doesn't come out the way
you'd like.

> Primarily, folks want to use it as in
> "Ethernet-over-MPLS".  That may not necessarily go down
> well with you either, but think of MPLS as a logical FR.

I think we need to retain a focus on connectionless,
packet-oriented delivery and how to build on that.  I wonder
if we aren't going considerably astray with the growing
emphasis on pseudo-circuits.

Melinda

RE: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Vach Kompella]

Melinda,

"We're doing it" is a statement of fact.  However, we've been doing it for over
two years.  Pseudo-wire work has been ongoing for over 4 years.  MPLS has been
ongoing since 1996 or thereabouts.

I know there are some who think the IETF shouldn't be working on MPLS and its
applications.  I think there are those who think it should be.  I haven't heard
anything that says we are doing this in opposition to a consensus who would like
to see MPLS disappear or move to some other organization.

So you may voice your personal "uh-oh" but show me the consensus "uh-oh" before
I stop.

-Vach

> -Original Message-
> From: Melinda Shore [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, June 18, 2003 10:18 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]
> Subject: Re: WG review: Layer 2 Virtual Private Networks (l2vpn)
>
>
> > We're doing it.
>
> That's an "uh-oh" comment.  It's very common to hear people
> say that the IETF doesn't know how to say "no" to new work.
> I think the real problem is that many people bringing new
> work to the IETF don't know how to accept being told "no"
> and it leads to harass-a-thons of the IESG on the one hand
> and dubious work on the other.  I think part of committing
> to working in collaborative organizations like the IETF is
> arguing your case the best you can but agreeing to accept
> community consensus even if it doesn't come out the way
> you'd like.
>
> > Primarily, folks want to use it as in
> > "Ethernet-over-MPLS".  That may not necessarily go down
> > well with you either, but think of MPLS as a logical FR.
>
> I think we need to retain a focus on connectionless,
> packet-oriented delivery and how to build on that.  I wonder
> if we aren't going considerably astray with the growing
> emphasis on pseudo-circuits.
>
> Melinda
>

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Eric Rescorla]

Keith Moore <[EMAIL PROTECTED]> writes:

> > If you want to address denial of service issues you need protocol
> > enforcement points.
> 
> NAT is a denial of service attack, not a means of policy enforcement.

I don't think this is really accurate.

The difference between denial of service and policy enforcement
is primarily a question of authorization. Since the people who
install NAT generally own the networks in question, characterizing
NAT as a DoS attack doesn't really seem right.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]
   Web Log: http://www.rtfm.com/movabletype

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Keith Moore]

> > NAT is a denial of service attack, not a means of policy enforcement.
> 
> I don't think this is really accurate.
> 
> The difference between denial of service and policy enforcement
> is primarily a question of authorization. Since the people who
> install NAT generally own the networks in question, characterizing
> NAT as a DoS attack doesn't really seem right.

people who run virus-laden programs are doing so because they want the
advertised functionality of that program, not because they want to infect
their systems or spread the virus.   people who use Microsoft mail readers do
so because they want to read mail, not because they want to expose their
systems to attack.

similarly, people who install NAT usually don't realize how much this
costs them in lost functionality and reliability.

perhaps DoS isn't quite the right term, but it's not far off.

Re: NAT box spec? (RE: myth of the great transition)

[james woodyatt]

On Tuesday, Jun 17, 2003, at 22:55 US/Pacific, Harald Tveit Alvestrand 
wrote:
at the risk of feeding into a long-burning flamewar:
when you say "a decent NAT box spec", what do you think of?
Now, you've done it.

As far as I can tell, a NAT box contains, over and above what it does 
because it's a router, a firewall or any other thing it might do:

- Address translation
- Application layer gatewaying
- Remote control of the NAT functionality (already being worked on in 
MIDCOM)

So what did you want a "decent NAT box spec" to say?

   Harald, genuinely curious
I maintain the NAT code (among other things) in the firmware of a 
consumer Wi-Fi/router product.  I'm not sure I can think of anything 
the IETF needs to do here beyond what it has already done-- or is in 
the process of finishing up.

I think the spec that Mr. Hallam-Baker would like to see is likely to 
emerge from outside the IETF.  In fact, I predict that several 
competing de facto standards will emerge in the market, and eventually 
one of them may win out-- but I'm pessimistic about that.

When customers of retail Internet service start demanding a NAT 
standard, then that's when the IETF might want to think about 
documenting the standard that the market seems to want.  Not before, I 
think.

I see no evidence that such demand exists now, or that it's very likely 
to exist in the foreseeable future.  Piteous whines from applications 
developers complaining about the weird menagerie of NAT implementations 
do *NOT* constitute an indication of real demand from retail Internet 
service customers.

The IETF has already decided how to proceed with addressing the 
limitations in IPv4 that make the deployment of NAT devices an optimal 
strategy in some cases.  We've seen how successful the IETF has been in 
persuading users that a new protocol is superior because it comes 
stamped with the magick 'Draft Standard' label.  I doubt that providing 
such a magick stamp for NAT devices would be worth the effort if the 
market isn't interested in products that claim to be compliant with it.

--
j h woodyatt <[EMAIL PROTECTED]>

Re: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Ping Pan]

Bob Braden wrote:
Harald,

Here is one more to consider: maybe it is outside the mainstream of the
Internet architecture.  [Optimizing to leave IP out of the stack and do
direct L2 communication certainly SOUNDS like a retrograde step to me,
too.  Twenty years ago I was arguing with a UCLA professor, who
insisted that IP was too much overhead and that he needed to do direct
LAN transmission to get adequate performance for his distributed file
system.  He eventually figured out the fallacy, because the product
produced by his company had the IP layer in place.  Have we forgotten
these lessons?]
Bob,

I think not. If you look like what people are working on in this area, 
it is all IP-driven:
 - at data plane, L2 flows are aggregated through GRE, MPLS... tunnels.
 - at control layer, it all IP: LDP, BGP, Radius...

Along with L3VPN, I argue this is mainstream Internet. If there is a 
problem, I start to worry if we are overloading some of the protocols. 
Well... if it aint broken, why fix it? :-)

If you concern about building nation-wide L2 bridging backbones with 
spanning trees running off the roof, :-) so far, I have not seen people 
seriously moving toward that direction.

As for IESG, the problem is not about having a new IETF WG. Rather, why 
are we spending so much time and energy on standardization? How many 
times are people going to write architecture and framework RFC's?

2 cents,

- Ping

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Eric Rescorla]

Keith Moore <[EMAIL PROTECTED]> writes:

> > > NAT is a denial of service attack, not a means of policy enforcement.
> > 
> > I don't think this is really accurate.
> > 
> > The difference between denial of service and policy enforcement
> > is primarily a question of authorization. Since the people who
> > install NAT generally own the networks in question, characterizing
> > NAT as a DoS attack doesn't really seem right.
> 
> people who run virus-laden programs are doing so because they want the
> advertised functionality of that program, not because they want to infect
> their systems or spread the virus.   people who use Microsoft mail readers do
> so because they want to read mail, not because they want to expose their
> systems to attack.
Yes, I totally agree with that. What's your point?

> similarly, people who install NAT usually don't realize how much this
> costs them in lost functionality and reliability.
Really? You have evidence of this?

I don't either, but my intuition is that you're wrong.  Once you have
decided to have a firewall in place (which you may think is evil, but
I consider pretty much a necessary evil), I suspect that most people
suffer almost not at all from having a NAT.

> perhaps DoS isn't quite the right term, but it's not far off.
I'm not sold.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]
http://www.rtfm.com/

RE: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Randy Bush]

> "We're doing it" is a statement of fact.  However, we've been
> doing it for over two years.  Pseudo-wire work has been ongoing
> for over 4 years.  MPLS has been ongoing since 1996 or
> thereabouts.

no disagreement.  the question i am hearing is not why is this
being done, but rather why is the ietf working on a an l2 over l2
protocol.  should we be doing frame over atm?  ether over atm?

randy

Re: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Paul Hoffman / VPNC]

At 10:15 AM +0200 6/18/03, Harald Tveit Alvestrand wrote:
I can think of some possible reasons, not necessarily exclusive

- this is a bad idea/impossible to do well, so we shouldn't do it
- some other organization is already doing it, so we shouldn't
- we're too stupid to get it right, so we shouldn't do it
- the IETF is too large, so we shouldn't be adding more work
This might be a combination of the latter three, but I think it is 
clearer for this WG:

- the IETF's track record for this work so far is quite poor

We have not shown any ability to create standards in this area with 
due speed or predictability. We have not shown the good judgement 
needed to limit the scope of the work we do. (Look at the number of 
L2VPN-based Working Group drafts in PWE3 and PPVPN, much less the 
large number of non-WG documents being actively discussed.

The IETF understands the need for layer 2 technologies for OAM much 
better than we understand the Internet customer's need (or even 
concern) for layer 2 transport of their IP packets. This is because 
we have a tighter relationship with operators than we do with 
Internet users, and because Internet users generally could care less 
about how their ISPs move their traffic as long as they meet the 
service level agreements. The ISPs would love to have better 
cross-vendor interop for the L2VPN technologies, but so far the 
vendors haven't had time to think about that because they have been 
overloaded with the literally dozens of flavors that are being 
discussed in the IETF.

We will never know if there is another organization who could do a 
better job than this because no other organization will take on the 
work while the 800-pound gorilla of standards bodies is flailing 
around in the area. There are certainly other organizations that can 
take it on, such as the MPLS and Frame Relay Alliance. They might do 
just as bad of a job as we have so far, but they could also do much 
better because they are much more focused.

--Paul Hoffman, Director
--VPN Consortium

Network 7

[matthew . ford]

Anyone know whether network 007/8 is 'IANA - Reserved' as IANA state here:
http://www.iana.org/assignments/ipv4-address-space or 'Allocated' as ARIN
state here:
ftp://ftp.arin.net/pub/stats/arin/arin.20030601?

Mat

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Keith Moore]

> > similarly, people who install NAT usually don't realize how much this
> > costs them in lost functionality and reliability.
> Really? You have evidence of this?

the evidence I have is from reading vendor advertisements for NAT boxes,
and from talking to people who run networks that use NAT.  it's not 
a random sample, perhaps not a statistically significant one, but it's
been enough to convince me personally that the delusion is widespread.

> I don't either, but my intuition is that you're wrong.  Once you have
> decided to have a firewall in place (which you may think is evil, but
> I consider pretty much a necessary evil), I suspect that most people
> suffer almost not at all from having a NAT.

depends on what you mean by "firewall"  (which these days is a pretty
vague term).  but there are several primary effects of NAT - one being
that addresses are not maintained end-to-end, another being that NATs
cause address-to-host bindings to be ephemeral when they would otherwise
not be, and another being that (for NAPTs anyway) attempts to initiate
traffic across the NAPT are blocked in one direction.  there is rarely
a significant benefit in a firewall doing the first two of these.  a good
firewall has the capability to block traffic in either direction, or not, on a
case-by-case basis, and can be adjusted according to the needs of its users. 

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Melinda Shore]

> The difference between denial of service and policy enforcement
> is primarily a question of authorization. Since the people who
> install NAT generally own the networks in question, characterizing
> NAT as a DoS attack doesn't really seem right.

Well, yeah, but ...  NAT is far too crude in its policy
capabilities to be able to credibly claim that it's a policy
enforcement device.  That's why we have all these ghastly
work-arounds - effectively they're for the purposes of
refining the policy semantics.  I think this may be one of
those cases where it's neither a furniture polish nor a
dessert topping.

I'm not sure that labelling it a "DoS attack" is
particularly helpful, though.

Melinda

Re: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Scott W Brim]

On Wed, Jun 18, 2003 01:18:10PM -0400, Melinda Shore allegedly wrote:
> I think we need to retain a focus on connectionless,
> packet-oriented delivery and how to build on that.  I wonder
> if we aren't going considerably astray with the growing
> emphasis on pseudo-circuits.

The IETF does continue to have an emphasis on connectionless,
packet-oriented delivery.  That's our fundamental architecture, without
question.  In the meantime there are customers who want to transition to
c, p-o d but need mechanisms for doing so.  Why did we spend any time on
transition from IPv4 to IPv6?  In order to make transition easier.  They
want to convert.  Do we say outsiders can't convert to our religion,
they can only be born into it?  Do you want them to define their own
ways to do [virtual] circuit emulation?  

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Eric Rescorla]

Keith Moore <[EMAIL PROTECTED]> writes:

> > > similarly, people who install NAT usually don't realize how much this
> > > costs them in lost functionality and reliability.
> > Really? You have evidence of this?
> 
> the evidence I have is from reading vendor advertisements for NAT boxes,
> and from talking to people who run networks that use NAT.  it's not 
> a random sample, perhaps not a statistically significant one, but it's
> been enough to convince me personally that the delusion is widespread.
You can perhaps understand why I wouldn't consider this a particularly
convincing line of argument.

> > I don't either, but my intuition is that you're wrong.  Once you have
> > decided to have a firewall in place (which you may think is evil, but
> > I consider pretty much a necessary evil), I suspect that most people
> > suffer almost not at all from having a NAT.
> 
> depends on what you mean by "firewall"  (which these days is a pretty
> vague term).  but there are several primary effects of NAT - one being
> that addresses are not maintained end-to-end, another being that NATs
> cause address-to-host bindings to be ephemeral when they would otherwise
> not be, and another being that (for NAPTs anyway) attempts to initiate
> traffic across the NAPT are blocked in one direction.  there is rarely
> a significant benefit in a firewall doing the first two of these.  a good
> firewall has the capability to block traffic in either direction, or not, on a
> case-by-case basis, and can be adjusted according to the needs of its users. 
Yes, but these are philosophical objections.

What applications that people want to run--and the IT managers would
want to enable--are actually inhibited by NAT? It seems to me that
most of the applications inconvenienced by NAT are ones that IT
managers would want to screen off anyway.

-Ekr
-- 
[Eric Rescorla   [EMAIL PROTECTED]
   Web Log: http://www.rtfm.com/movabletype

Re: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Uri Blumenthal]

On 6/18/2003 1:18 PM, Melinda Shore wrote:
>>We're doing it.
> 
> ...the real problem is that many people bringing new
> work to the IETF don't know how to accept being told "no"
> and it leads to harass-a-thons of the IESG on the one hand
> and dubious work on the other. 

:-) :-)

I agree.

>>Primarily, folks want to use it as in
>>"Ethernet-over-MPLS".  That may not necessarily go down
>>well with you either, but think of MPLS as a logical FR.
> 
> I think we need to retain a focus on connectionless,
> packet-oriented delivery and how to build on that.  I wonder
> if we aren't going considerably astray with the growing
> emphasis on pseudo-circuits.

Again, I agree and support.

Re: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Kurt Erik Lindqvist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

>>  - we must not overload routing protocols and such infrastructure 
>> (IMHO,
>> this seems an inevitable path the work would go towards..)
>>
>
> If you use LDP, it is NOT a routing protocol.  The specific mode of use
> (targeted LDP) is already described in RFC 3036.  The FECs are 
> different, but
> the FEC TLV was defined in such a way as to be extensible.

And when you want to do this inter-domain? Everything else seems to 
have made it's way into BGP so I think that Pekkas concerns are valid...

>>  - we must not create complexity by deploying ethernet bridging all 
>> over
>> the Internet.  Our work should be focused on making IP work, not
>> specifying Ethernet-over-IP (or worse, Ethernet-over-IP as a 
>> *service*).
>>
>
> Primarily, folks want to use it as in "Ethernet-over-MPLS".  That may 
> not
> necessarily go down well with you either, but think of MPLS as a 
> logical FR.
> Providers do not want to change their infrastructure, e.g., replace a 
> FR cloud
> with an ATM cloud, then with SONET or GigE.  That's mega-expensive.  By
> abstracting the L2 using MPLS, they can provide the L2VPN service 
> without
> wholesale infrastructure replacement.

Most of these providers have bought what their vendor told them to buy, 
but let's not go into that here.

>
>>  - it is architecturally wrong: use different subnets, period -- 
>> that's
>> what those are meant for in the first place!
>
> Use different subnets to create VPNs?  I don't understand what you 
> mean.  VPLS
> and VPWS address a requirement for multiple domains (aka VPNs), 
> logically
> distinct from and invisible to each other.

Pekka is right in that most of the applications of VPNs today could 
actually be solved as good with "real addresses" and routing across 
networks.

>> Btw. how is this different from currently-specified GRE tunneling?  It
>> being made a "service"?
>
> GRE-tunneling is one option, but only for the transport of the VC.  
> However, you
> need a demux field to identify the VC that you are carrying.  Carrying 
> one
> customer VC between a pair of PEs is obviously not adequate.

L2TPv3? Whats the advantage with this over the existing protocol that 
the IETF have?

> - kurtis -

-BEGIN PGP SIGNATURE-
Version: PGP 8.0.2

iQA/AwUBPvCyBKarNKXTPFCVEQL6DQCfSLe3xKzNpU+Me8j4lFuGJojeu+oAoKAP
WdkmzQyNXqX4UfhZdIc8XX1g
=iysk
-END PGP SIGNATURE-

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Kurt Erik Lindqvist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

> If you want to address denial of service issues you need protocol
> enforcement points.

Protocol enforcement points have so far failed to scale (today called 
border routers). What you need is to fix a much wider problem.

- - kurtis -

-BEGIN PGP SIGNATURE-
Version: PGP 8.0.2

iQA/AwUBPvCyXqarNKXTPFCVEQLk9QCeKez7+Z+rMZ0NAsTSads75v9bP3wAmgP7
WG3EHWur0S0G+pjg/eahGGTC
=mVIP
-END PGP SIGNATURE-

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Keith Moore]

> > the evidence I have is from reading vendor advertisements for NAT
> > boxes, and from talking to people who run networks that use NAT. 
> > it's not a random sample, perhaps not a statistically significant
> > one, but it's been enough to convince me personally that the
> > delusion is widespread.
>
> You can perhaps understand why I wouldn't consider this a particularly
> convincing line of argument.

of course.  but you can perhaps understand why I don't consider your 
intiution to the contrary convincing either?

> What applications that people want to run--and the IT managers would
> want to enable--are actually inhibited by NAT? 

depends on the people.  the people I work with want to run large-scale
distributed computing problems.  other people want to use SIP to support
internet telephony or for some other purpose.  others want to use
IPsec...  yes there are workarounds for many of these, but they have to
be invented on a case-by-case basis, and often they're expensive.

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[S Woodside]

On Wednesday, June 18, 2003, at 12:59  PM, Hallam-Baker, Phillip wrote:

Not at all.

If you want to address denial of service issues you need protocol
enforcement points.
This sounds like you are equating a NAT box with a firewall, which 
seems to be common.

I would like to know:
- Is a NAT box a protocol enforcement point?
- is it an EFFECTIVE protocol enforcement point?
- is a NAT a firewall? (many people seem to think it is ...)
- is a firewall a protocol enforcement point? (yes)
- does a protocol enforcement point, have to include a NAT?
- does an EFFECTIVE one have to include a NAT?
- is it even EASIER to enforce protocol issues with a NAT as opposed to 
other means?

simon

I really wish that the IETF
had designed a decent NAT box spec
that's an oxymoron.  the basic premis of NAT is fundamnetally broken.
--
www.simonwoodside.com -- 99% Devil, 1% Angel

RE: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Putzolu, David]

> NAT is a denial of service attack, not a means of policy enforcement.

I wonder if NAT is to ietf discussions as Nazis was 
to Usenet discussions.

That is, will every heated IETF debate eventually lead to
invoking the NAT bogyman?

And if that where to be true, would the corollary apply
that the discussion is no longer fruitful?

Cheers,
David

Re: SIRs

[S Woodside]

On Tuesday, June 17, 2003, at 12:17  PM, Bob Braden wrote:

  *> Create a document-based thread rather than a WG-based or
  *> mailing-list-based thread. Patches could also be posted and 
revision
  *> history (changes between revisions) would be easier to keep track 
of.
  *> People who have negative comments could post them, and they'd be 
part
  *> of the history record of the draft even if their comments are
  *> ignored/rejected.
  *>
  *> simon

I really wonder whether people have thought through the can of
worms (Pandora's box) that you people may be opening...?  This is not
to deny the need to improve the quality of some I-Ds and RFCs,
goodness knows, but be careful of social consequences...
I've observed several bug-database oriented cultures, including the 
public mozilla bugzilla database. One interesting observation of 
bugzilla is that they do not permit referral from slashdot ... most 
obviously that would be to avoid the /. effect, but also, to avoid the 
kind of spamming effect that could occur if some influential person 
says "this thing at url XYZ is evil, go post a negative comment on it".

There is no reason otherwise, that the bugtracker would engender a 
reduced quality of discourse about an I-D. Since, the technical level 
of sophistication to read and understand an I-D would still be there, 
and the sophistication to post a message on a website is just as high 
as posting on a mailing list (and see the bugzilla page, they do make 
it difficult enough). Whereas, it would greatly help the situation 
where I read an I-D and think -- but wait, what about foo, they seem to 
have missed that -- and jump to the bugtracker and can easily find that 
the issue has already been raised and see if/what justifications are.

simon

Re: myth of the great transition

[S Woodside]

Once you have
decided to have a firewall in place (which you may think is evil, but
I consider pretty much a necessary evil)
If by firewall, you mean "a box that can perform policy enforcement" 
then I don't think that many people in the IETF would think that's an 
evil thing. The problem is more that the general public seems to 
conflate firewall and NAT. Perhaps a new word is needed for "a box that 
can perform policy enforcement".

simon

--
www.simonwoodside.com -- 99% Devil, 1% Angel

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Michael Thomas]

Eric Rescorla writes:
 > Keith Moore <[EMAIL PROTECTED]> writes:
 > > similarly, people who install NAT usually don't realize how much this
 > > costs them in lost functionality and reliability.
 > Really? You have evidence of this?
 > 
 > I don't either, but my intuition is that you're wrong.  Once you have
 > decided to have a firewall in place (which you may think is evil, but
 > I consider pretty much a necessary evil), I suspect that most people
 > suffer almost not at all from having a NAT.

I think Keith's point is that most people don't
realize what voodoo their box is doing until
something doesn't work. And then it just doesn't
work because it doesn't work. It's an attack of
engineering cynicism.

 Mike

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Eric Rescorla]

Keith Moore <[EMAIL PROTECTED]> writes:

> > > the evidence I have is from reading vendor advertisements for NAT
> > > boxes, and from talking to people who run networks that use NAT. 
> > > it's not a random sample, perhaps not a statistically significant
> > > one, but it's been enough to convince me personally that the
> > > delusion is widespread.
> >
> > You can perhaps understand why I wouldn't consider this a particularly
> > convincing line of argument.
> 
> of course.  but you can perhaps understand why I don't consider your 
> intiution to the contrary convincing either?

Yes, but I'm not the one calling widely sold and deployed network
devices "Denial of service attacks". 


> depends on the people.  the people I work with want to run large-scale
> distributed computing problems.  other people want to use SIP to support
> internet telephony or for some other purpose.  others want to use
> IPsec...  yes there are workarounds for many of these, but they have to
> be invented on a case-by-case basis, and often they're expensive.
I don't know enough about how you're doing your distributing computing
to have an opinion, but as for the other two... In my experience,
IT managers are pretty unhappy punching holes in their firewalls
for incoming SIP and IPsec, whether they run NAT or not. I'm
not sure that NAT is much of an impediment in these cases.

The bottom line here is what economists call "revealed preference".
People buy NATs and install them. I suppose it's possible that all
those people are stupid and the marginal utility of a NAT box is
actually negative, but that seems like a claim that would require some
pretty strong evidence.

-Ekr


-- 
[Eric Rescorla   [EMAIL PROTECTED]
   Web Log: http://www.rtfm.com/movabletype

Re: myth of the great transition

[S Woodside]

On Monday, June 16, 2003, at 11:05  PM, John C Klensin wrote:

small enterprise and SOHO multihoming may turn out to be one of the 
driving applications for IPv6. If we get our act sufficiently 
together...
Absolutely. This and the peer2peer advantages sound to me like the most 
obvious drivers for v6 adoption.

The only problem with the p2p is the risk that the 
RIAA/MPAA/evilcopyrightholders will brand IPv6 as a bad technology 
that's contributing to infringement ;-)

simon

--
www.simonwoodside.com -- 99% Devil, 1% Angel

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Bob Braden]

  *> 
  *> > If you want to address denial of service issues you need protocol
  *> > enforcement points.
  *> 
  *> NAT is a denial of service attack, not a means of policy enforcement.
  *> 
  *> 
  *> 

Keith,

I think it would be more accurate to say that a NAT contravenes
the basic Internet prnciple of universal connectivity.

Since 1980 we have believed that universal connectivity was one of the
great achievements of the Internet design.  Today, one must
unfortunately question whether universal connectivity can be sustained
(or is even the right goal) in a networking environment without
universal trust.  Maybe NATs are, in fact, a result of a very deep
problem with our architecture.  If you accept that, then there is no
point in attacking NATs until you can propose a better architectural
solution to the trust problem (hopefully, there will be one!)

Bob Braden

Re: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Melinda Shore]

> The IETF does continue to have an emphasis on connectionless,
> packet-oriented delivery.  That's our fundamental architecture, without
> question.  In the meantime there are customers who want to transition to
> c, p-o d but need mechanisms for doing so.

Personally I'd find this proposal more compelling if it
were being presented as being oriented towards transitional
mechanisms.  We're seeing circuit-y proposals show up in
other working groups and I'm concerned that these reflect a
shift in basic assumptions about the characteristics of the
underlying network, at least among a non-trivial number of
participants.  

As a process kind of thing, I'm also concerned about the
growth of the "temporary" sub-IP area, so I think there are
issues here with both the work itself and in how the IETF
goes about taking on and structuring its work.

Melinda

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Keith Moore]

> > of course.  but you can perhaps understand why I don't consider your
> > 
> > intiution to the contrary convincing either?
> 
> Yes, but I'm not the one calling widely sold and deployed network
> devices "Denial of service attacks". 

Just for comparison against Phil's use of the term.  It's not how I
normally describe them (though I'm not exactly glowing in my praise...)

> I don't know enough about how you're doing your distributing computing
> to have an opinion, but as for the other two... In my experience,
> IT managers are pretty unhappy punching holes in their firewalls
> for incoming SIP and IPsec, whether they run NAT or not.

In my experience, IT managers are generally pretty unhappy changing
anything to support their users.  People who actually use the computers
or the network are regarded as a nuisance.

> The bottom line here is what economists call "revealed preference".

Maybe "revealed ignorance" would be a better term.  Though I prefer
"unintended consequence".

Keith

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Melinda Shore]

> What applications that people want to run--and the IT managers would
> want to enable--are actually inhibited by NAT? It seems to me that
> most of the applications inconvenienced by NAT are ones that IT
> managers would want to screen off anyway.

Not really.  For example, ftp as originally defined doesn't
work through NATs, and no standard VoIP or multimedia
conferencing protocol works through NAT.  

What I think is a huge problem that people tend to be pretty
hand-wavy about is that many of the mechanisms that are
introduced to help complex applications work through NATs
introduce new security exposures, whether it's the
"pseudo-NAT attack" described by Dupont and that we've run
into with STUN, or external relays allowing internal users
to run unauthorized servers, or stateful inspection/rewrite
forcing application users not to use encryption or integrity
protection, or ...  NAT has a surprisingly wide ripple
effect that's almost completely negative.

Melinda

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Keith Moore]

> I think it would be more accurate to say that a NAT contravenes
> the basic Internet prnciple of universal connectivity.

well, if we're going to try to get accurate (or even precise) I'd
venture that the basic principle being contravened is not universal
connectivity, but separation of function between the network and the
endpoints - where the network's job is to make a best effort to deliver
packets to where the endpoints want them to go.  expecting the network
to isolate insecure hosts from untrustworthy attackers, or more
generally, to enforce policy about what kinds of content are
permitted to pass, has always been a stretch.  

Keith

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Eric A. Hall]

on 6/18/2003 1:31 PM Eric Rescorla wrote:

> What applications that people want to run--and the IT managers would 
> want to enable--are actually inhibited by NAT? It seems to me that most
> of the applications inconvenienced by NAT are ones that IT managers
> would want to screen off anyway.

Oracle and H.323 have both been historically problematic, and are both
reasonable applications. Home users also suffer a lot with perfectly
innocent services like games. Ignoring the rifle-shot arguments, requiring
an application to be rebuilt or that a middlebox learn to ~emulate an
active end-point are both miserable choices, and generally unnecessary.

-- 
Eric A. Hallhttp://www.ehsco.com/
Internet Core Protocols  http://www.oreilly.com/catalog/coreprot/

Re: NAT box spec? (RE: myth of the great transition)

[Keith Moore]

> When customers of retail Internet service start demanding a NAT 
> standard, then that's when the IETF might want to think about 
> documenting the standard that the market seems to want.  

here's the only thing that a NAT standard should say:

an intermediary MUST NOT alter the source or destination field in an IP
header.

an intermediary MUST NOT route an IP packet to other than its intended
destination.

an intermediary MUST NOT alter the payload of an IP packet.

RE: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Vach Kompella]

> >
> > If you use LDP, it is NOT a routing protocol.  The specific mode of use
> > (targeted LDP) is already described in RFC 3036.  The FECs are
> > different, but
> > the FEC TLV was defined in such a way as to be extensible.
>
> And when you want to do this inter-domain? Everything else seems to
> have made it's way into BGP so I think that Pekkas concerns are valid...

That's only because the IETF hasn't made security easy enough, light enough, or
something.  Now some people use the argument that everything should go into BGP
because "opening another port into the provider network is a security breach."
Why is port 646 (LDP) any more insecure than port 179 (BGP)?

>
> >>  - we must not create complexity by deploying ethernet bridging all
> >> over
> >> the Internet.  Our work should be focused on making IP work, not
> >> specifying Ethernet-over-IP (or worse, Ethernet-over-IP as a
> >> *service*).
> >>
> >
> > Primarily, folks want to use it as in "Ethernet-over-MPLS".  That may
> > not
> > necessarily go down well with you either, but think of MPLS as a
> > logical FR.
> > Providers do not want to change their infrastructure, e.g., replace a
> > FR cloud
> > with an ATM cloud, then with SONET or GigE.  That's mega-expensive.  By
> > abstracting the L2 using MPLS, they can provide the L2VPN service
> > without
> > wholesale infrastructure replacement.
>
> Most of these providers have bought what their vendor told them to buy,
> but let's not go into that here.
>

Sheesh!  No, let's go there.  You're talking about my potential customers, and I
want to know if they really are so dense that I shouldn't have been spending all
this time working on a protocol - I could have just given them a couple of
high-priced tin cans and a piece of string.

Who exactly the IETF is going to be providing protocols for?  For protocols such
as these, it is the providers who deploy them.  You claim that most of the
providers have little or no discernment.  Let's give credit to the providers.
There are a large number of them who know what they are doing.  Many of them
participate in the standards.

> >
> >>  - it is architecturally wrong: use different subnets, period --
> >> that's
> >> what those are meant for in the first place!
> >
> > Use different subnets to create VPNs?  I don't understand what you
> > mean.  VPLS
> > and VPWS address a requirement for multiple domains (aka VPNs),
> > logically
> > distinct from and invisible to each other.
>
> Pekka is right in that most of the applications of VPNs today could
> actually be solved as good with "real addresses" and routing across
> networks.

You probably haven't read the requirements documents then.

>
> >> Btw. how is this different from currently-specified GRE tunneling?  It
> >> being made a "service"?
> >
> > GRE-tunneling is one option, but only for the transport of the VC.
> > However, you
> > need a demux field to identify the VC that you are carrying.  Carrying
> > one
> > customer VC between a pair of PEs is obviously not adequate.
>
> L2TPv3? Whats the advantage with this over the existing protocol that
> the IETF have?
>
> > - kurtis -
>

-Vach

RE: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Vach Kompella]

Paul,

>
> At 10:15 AM +0200 6/18/03, Harald Tveit Alvestrand wrote:
> >I can think of some possible reasons, not necessarily exclusive
> >
> >- this is a bad idea/impossible to do well, so we shouldn't do it
> >- some other organization is already doing it, so we shouldn't
> >- we're too stupid to get it right, so we shouldn't do it
> >- the IETF is too large, so we shouldn't be adding more work
>
> This might be a combination of the latter three, but I think it is
> clearer for this WG:
>
> - the IETF's track record for this work so far is quite poor
>

That's not a problem of the ppvpn group only.  It is a problem of the IETF.

I don't need to refresh your memory about IPSec, do I?  SKIP, Skeme, Oakley,
IKE.  AH or ESP with auth?  5 years of bloody fighting.

It's wherever the action is that the political jostling for position is the most
prominent.  That's also where the leadership needs to be strong and participants
need to have a "nose to the grindstone" attitude.  That's hardly an indication
that the work should not be chartered or worked upon.

> We have not shown any ability to create standards in this area with
> due speed or predictability. We have not shown the good judgement
> needed to limit the scope of the work we do. (Look at the number of
> L2VPN-based Working Group drafts in PWE3 and PPVPN, much less the
> large number of non-WG documents being actively discussed.

Do you think the new L2VPN charter addresses these concerns of scoping?  How
about the timelines?  Basically, it's going to be a WG issue, chairs and
participants, to finish the WG charter items first.

>
> The IETF understands the need for layer 2 technologies for OAM much
> better than we understand the Internet customer's need (or even
> concern) for layer 2 transport of their IP packets. This is because
> we have a tighter relationship with operators than we do with
> Internet users, and because Internet users generally could care less
> about how their ISPs move their traffic as long as they meet the
> service level agreements. The ISPs would love to have better
> cross-vendor interop for the L2VPN technologies, but so far the
> vendors haven't had time to think about that because they have been
> overloaded with the literally dozens of flavors that are being
> discussed in the IETF.

Are you talking PWE3 or L2VPN?

The gazillion drafts is in PWE3.  The interop issues are localized to the drafts
with contention, silly issues of where bits should go.

There are 16 pseudowire types:
   0x0001   Frame Relay DLCI
   0x0002   ATM AAL5 SDU VCC transport
   0x0003   ATM transparent cell transport
   0x0004   Ethernet Tagged Mode
   0x0005   Ethernet
   0x0006   HDLC
   0x0007   PPP
   0x0008   SONET/SDH Circuit Emulation Service Over MPLS (CEM) [8]
   0x0009   ATM n-to-one VCC cell transport
   0x000A   ATM n-to-one VPC cell transport
   0x000B   IP Layer2 Transport
   0x000C   ATM one-to-one VCC Cell Mode
   0x000D   ATM one-to-one VPC Cell Mode
   0x000E   ATM AAL5 PDU VCC transport
   0x000F   Frame-Relay Port mode
   0x0010   SONET/SDH Circuit Emulation over Packet (CEP)

At least half of these are and have been interoperable.  It is the harder (and
more arcane, IMHO) PW types that people are having a hard time coming to some
sort of compromise.

BTW, I'm glad to see you have a healthier respect for providers than Kurtis who
claims that "most of these providers have bought what their vendor told them to
buy."

>
> We will never know if there is another organization who could do a
> better job than this because no other organization will take on the
> work while the 800-pound gorilla of standards bodies is flailing
> around in the area. There are certainly other organizations that can
> take it on, such as the MPLS and Frame Relay Alliance. They might do
> just as bad of a job as we have so far, but they could also do much
> better because they are much more focused.

An 800-pound gorilla conjures up images of one less nimble of foot.  IMHO, not
the right metaphor for the IETF.

>
> --Paul Hoffman, Director
> --VPN Consortium
>
>

-Vach

RE: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Vach Kompella]

Melinda,

>
> As a process kind of thing, I'm also concerned about the
> growth of the "temporary" sub-IP area, so I think there are
> issues here with both the work itself and in how the IETF
> goes about taking on and structuring its work.

And proposals have been made to dismantle the SUBIP area and place the remaining
WGs in the most appropriate areas (some of them are pretty much done with their
chartered work).  The chartering of L2 and L3VPN WGs gives a little more focus,
and limits the solution space.

It's not the creation of the temporary SUBIP area that caused the growth of the
WGs.  It's the natural progression of the opportunities that MPLS provided that
led to the application WGs such as PWE3, PPVPN, etc.

>
> Melinda
>

-Vach

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Iljitsch van Beijnum]

On woensdag, jun 18, 2003, at 21:17 Europe/Amsterdam, Bob Braden wrote:

Since 1980 we have believed that universal connectivity was one of the
great achievements of the Internet design.  Today, one must
unfortunately question whether universal connectivity can be sustained
(or is even the right goal) in a networking environment without
universal trust.
I think we can safely say that 99.99% of all systems that run IP don't 
want to talk to 99.99% of all systems that run IP. For most people, 
with a network this large, universal connectivity isn't a goal but a 
threat. But this shouldn't be confused with universal addressability 
being undesirable, because this only gets more important as the size of 
the network increases.

Maybe NATs are, in fact, a result of a very deep
problem with our architecture.
Yes, that IP addresses are only 32 bits. So people decided to usurp the 
16 bit port number to create virtual 48 bit IP addresses.

If you accept that, then there is no
point in attacking NATs until you can propose a better architectural
solution to the trust problem (hopefully, there will be one!)
What we need is a good way to limit access to systems. Firewalls look 
at addresses and port numbers, which are mostly meaningless. So people 
hide their boxes behind NATs and bastion hosts to gain some security. 
If we can solve this IPv6 will take care of the rest.

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Michael Thomas]

Bob Braden writes:
 > Since 1980 we have believed that universal connectivity was one of the
 > great achievements of the Internet design.  Today, one must
 > unfortunately question whether universal connectivity can be sustained
 > (or is even the right goal) in a networking environment without
 > universal trust.  Maybe NATs are, in fact, a result of a very deep
 > problem with our architecture.  If you accept that, then there is no
 > point in attacking NATs until you can propose a better architectural
 > solution to the trust problem (hopefully, there will be one!)

I sort of wonder the same thing, but I don't draw
the major distinction with trust. In fact, NAT's
are lousy at that, unless you're talking about
NAT's qua ALG's. 

My big bugaboo here is whether the factors driving
people to want address space they control beyond
the illusion of NAT security -- mostly renumbering
immunity, IMO -- is so hard to counter with the
universal end to end model version of the world
(eg, IPv6) that addressing realms are a given and
need to be dealt with just like civil engineers
need to deal with politicians who want to put
busts of their likeness into the faces of dams,
etc.

I personally am not ready to give up on the
promise and architectural tidiness of e2e, but I
have to say as an engineer it's never a bad plan
to make certain the intertia of the world is kept
in mind. Systems which are "correct" but
undeployed are a dime a dozen in the ash heap of
history.

Mike

Re: Last Call: LDP DoD Graceful Restart to Draft Standard

[Adrian Farrel]

Did anyone decide there was an error here, or is this draft really in IETF last
call?

Thanks
Adrian
- Original Message -
From: "Adrian Farrel" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, June 13, 2003 5:23 PM
Subject: Re: Last Call: LDP DoD Graceful Restart to Draft Standard


> With respect, this draft doesn't appear to have been through WG last call
> (unless I was sleeping, but I can't find any reference in the mail archive).
>
> It was only published as a WG draft on 5/7/2003 (despite carrying a date of
> February 2003).
>
> While I support the draft, I would like to see it discussed on the mailing
list
> and go through WG last call.
>
> Thanks,
> Adrian
>
> - Original Message -
> From: "The IESG" <[EMAIL PROTECTED]>
> To: 
> Cc: <[EMAIL PROTECTED]>
> Sent: Friday, June 13, 2003 1:59 PM
> Subject: Last Call: LDP DoD Graceful Restart to Draft Standard
>
>
> > ---
> > The IESG has received a request from Multiprotocol Label Switching to
> > consider the following Internet-Draft(s) as Draft Standard.
> > o Multiprotocol Label Switching (MPLS): LDP DoD Graceful Restart
> >   
> >   Draft Standard
> >
> >
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action.  Please send any comments to the
> > [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by .
> >
> > Files can be obtained via
> > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-dod-restart-00.txt
> >
>
>

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[J. Noel Chiappa]

> From: Keith Moore <[EMAIL PROTECTED]>

> that's an oxymoron. the basic premis of NAT is fundamnetally broken.

Just out of interest, do you complain about gravity too?

We lost our chance to avoid NAT's when variable length addresses were removed
from TCPv2.5 (IIRC the version number correctly). NAT's are here, like it or
not, and the only question is how to make lemonade out of them. 

Noel

PS: Speaking of gravity, does anyone have a copy of that great hack CMU memo
about how they were going to turn gravity off in the CS building on the
weekend to help everyone move offices?

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Keith Moore]

> > NAT is a denial of service attack, not a means of policy
> > enforcement.
> 
> I wonder if NAT is to ietf discussions as Nazis was 
> to Usenet discussions.
> 
> That is, will every heated IETF debate eventually lead to
> invoking the NAT bogyman?

The national socialist party is (hopefully) a thing of the distant past.
NATs, OTOH, are very much still with us.

I think we often end up talking about NATs because NATs are a symptom
that our architecture has fundamental unsolved problems that we so far
have failed to address (or that the market has failed to adopt, but
it's closer to the former, I think.)

The SPAM problem is another one of those recurring discussions that
never seems to be resolved, for similar reasons.

If we had a workable solution in hand for either problem, there would be
little point in our talking about them.  As it is, we keep revisiting
them in the hope that some new idea will emerge, or that some bit of
denial about those problems will go away.

Keith

RE: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Hallam-Baker, Phillip]

That is how we got here. Ignore it, hope it will go away.

What I am suggesting is that there is no reason nat had to reusult in being
on the interNOT rather than the internet.

Further folk are going to buy these and put them at the border of their home
networks. 

Trying to secure end point computers is futile. There will always be holes,
the attackers only need to own one percent of the internet to be able to
create havoc.

I note also that even though linux boxes are not a large percentage of net
they are prime targets for hackers. I suspect because they tend to be
connected to unrestircted dsl lines more often than capability limited cable
modems.

If I dot run a local mail server why should I let a machine have
unrestricted net access if it does not need it? Why allow one of my machines
to syn flood? Present a smaller prize to the hackers and you are less likely
to have severe problems.

End to end only security dogma is like saying buildings should be fireproof
and sprikler systems are evil and unnecessary



 -Original Message-
From:   Putzolu, David
Sent:   Wed Jun 18 13:59:43 2003
To: 'Keith Moore'; Hallam-Baker, Phillip
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject:RE: myth of the great transition (was US Defense Department
forma lly adopts IPv6)

> NAT is a denial of service attack, not a means of policy enforcement.

I wonder if NAT is to ietf discussions as Nazis was 
to Usenet discussions.

That is, will every heated IETF debate eventually lead to
invoking the NAT bogyman?

And if that where to be true, would the corollary apply
that the discussion is no longer fruitful?

Cheers,
David

RE: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Putzolu, David]

The IAB has talked about NAT.  A WG has produced a bunch of
RFCs about NAT.  NAT is very widely deployed and comes in
10 different flavors.  NAT has a bunch of architectural 
ugliness and technical problems.  So?

How about some lemonade?  An Internet draft that says 
something new about NATs would be a lot more helpful than 
rehashing the same old arguments.

Cheers,
David


> I think we often end up talking about NATs because NATs are a symptom
> that our architecture has fundamental unsolved problems that we so far
> have failed to address (or that the market has failed to adopt, but
> it's closer to the former, I think.)
> 
> The SPAM problem is another one of those recurring discussions that
> never seems to be resolved, for similar reasons.
> 
> If we had a workable solution in hand for either problem, 
> there would be
> little point in our talking about them.  As it is, we keep revisiting
> them in the hope that some new idea will emerge, or that some bit of
> denial about those problems will go away.
> 
> Keith
> 

RE: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Fleischman, Eric]

Eric Rescorla [mailto:[EMAIL PROTECTED] wrote:

>> similarly, people who install NAT usually don't realize how much this
>> costs them in lost functionality and reliability.

>Really? You have evidence of this?

>I don't either, but my intuition is that you're wrong.  Once you have
>decided to have a firewall in place (which you may think is evil, but
>I consider pretty much a necessary evil), I suspect that most people
>suffer almost not at all from having a NAT.

I believe that Eric is pointing out an important point: many deployments of NATs have 
nothing to do with IPv4 address conservation. Rather, they are firewall adjuncts 
implemented to hide internal networks from outside scrutiny and direct access. 

One point where I disagree with my IPv6-advocating friends is that I expect 
firewall-related NATs to continue to be deployed within Internet (including IPv6) 
environments until such a time as real-time-protocol and peer-to-peer-protocol 
friendly "distributed firewall" (policy zones) variants become the preferable "due 
diligence" alternative for CIOs.

NATs are NOT Firewalls

[Tomson Eric \(Yahoo.fr\)]

First of all, for the purists : I apologize for this simplified explanation
of what firewalls are. I guess we could start a very long thread about
firewalls and NATs, but the idea is to give a (somewhat) short answer (maybe
over-simplified) to some short questions asked by Simon Woodside (see
bottom).
-

There is not ONE firewall. A firewall is not a product, it's more like a
concept. The idea of a firewall is to build a protecting wall between an
external (public) network and an internal (private) network, by granting or
denying incoming/outgoing packets based on specified/configured
rules/policies. In the real world, there are different kinds of firewalls.

Compared to the OSI or TCP/IP layers, firewalls can work at different
layers.

There are mainly :
1.packet filters (analyze the IP packet and identify the IP addresses and
port numbers, then apply a set of rules),
2.circuit level gateways (work mainly at session layer, by identifying flows
of data and established connections),
3.application level gateways or proxies (application specific : http, ftp,
telnet,... with possible extended features, like caching possibilities,
logging of user activity,...), and
4.stateful inspection firewalls (more recent, combinations of types 1. 2.
and 3., more performant than 1. and 2., less complex than 3.).

A simple router, using access lists based on the IP addresses, analyzing
each packet one by one, is a basic firewall of type 1.
A more advanced device, able to identify "conversations", "sessions", is a
bit more advanced firewall of type 2.
A complex software, configured to analyze the addresses, the port numbers,
the protocols in use, possibly the contents of the applications data, is a
very complex firewall of type 3.

A basic router (not a firewall) will "transparently" interconnect different
networks, maintain routing tables, and advertise those tables to its
neighbors.
A NAT will "mask" the internal addresses, only maintain its own private
translation table, and not transmit it to any other device.

A Network Address Translator will usually translate "n" public, official IP
addresses into "n" private, internal IP addresses and keep the current port
numbers unchanged.
A Network Address and Port Translator will usually translate ONE public,
official IP address into SEVERAL private, internal IP addresses by
translating the external port numbers to correspond to the different
internal combinations of  (external packets will
only transport ONE IP address - the public, official one).

Pure NATs will only translate network addresses. PATs and NAPTs will
translate port numbers, too. In no case will any of them translate the
protocols - that would prevent clients and servers from understanding each
other (a web client with a telnet server, etc.).

NATs will mask the internal addresses from outside view, but won't use
policies, control the traffic, perform authentication, or prevent spoofing :
NATs ARE NOT FIREWALLS!!!

On the other hand, circuit level gateways and application level gateways
transparently perform address translation!!! The addresses of the internal,
private network are masked from outside view!
Packet filters and stateful inspection firewalls don't translate IP
addresses and port numbers.

So, in short :
1/ a NAT is not equal to a firewall, it's not a firewall! Some firewalls DO
perform Network Address Translation, but NATs DO NOT perform firewalling!
2/ the main, primary purpose of a NAT is to use a limited set of public
(external) IP addresses and make them correspond to a wider range of private
(internal) IP addresses, in order to make savings, either in terms of IPv4
addresses, or because it's simply cheaper than buying several public IPv4
addresses. Now, the fact that masking the internal addresses to the external
world - so that internal hosts can initiate traffic to the outside, but no
external host can initiate traffic to the inside - brings some basic
security, is an interesting corollary, but not the primary objective of a
NAT.

Hope this helps. And sorry again for the purists. ;)

E.T.
ICT Consultant and Trainer.
Member of IEEE, IPv6 Task Force, ISOC, PIR.

=>-Original Message-
=>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
=>Behalf Of S Woodside
=>
(...)
=>
=>This sounds like you are equating a NAT box with a firewall, which 
=>seems to be common.
=>
=>I would like to know:
=>- Is a NAT box a protocol enforcement point?
=>- is it an EFFECTIVE protocol enforcement point?
=>- is a NAT a firewall? (many people seem to think it is ...)
=>- is a firewall a protocol enforcement point? (yes)
=>- does a protocol enforcement point, have to include a NAT?
=>- does an EFFECTIVE one have to include a NAT?
=>- is it even EASIER to enforce protocol issues with a NAT as 
=>opposed to 
=>other means?
=>
=>simon
(...)

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Keith Moore]

> What I am suggesting is that there is no reason nat had to reusult in
> being on the interNOT rather than the internet.

you're simply wrong about that, at least for anything resembling today's
NATs.   except for a shortage of IPv4 addresses, NATs would not be
needed at all.  (yes, they're sold for other purposes, but they're
not needed for those purposes)  and there's no way to fix that shortage
in a sane fashion (or as you put it, without producing the interNOT)
that does not require changes to the endpoints - and in many cases, the
applications - to make them work. once you do that you're within epsilon
of the deployment barrier to IPv6.  (had IPv6 been designed
differently we might have been able to avoid having those changes affect
the network core, but not leaf networks or endpoints.)

> Further folk are going to buy these and put them at the border of
> their home networks. 

yup, and there will continue to be vendors selling snake oil.  it's not
our problem.

> Trying to secure end point computers is futile.

it's even more futile to expect the network to do it.  firewalls can
raise the bar for some kinds of threats, but they can't make your
insecure systems secure.

> If I dot run a local mail server why should I let a machine have
> unrestricted net access if it does not need it? 

no reason that I know of.  but the relevant question for this dicussion
is, why do you need a NAT to impose access control?  answer: you don't.

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Keith Moore]

> The IAB has talked about NAT.  A WG has produced a bunch of
> RFCs about NAT.  

the WG ended up being full of NAT vendors trying to legitimize NAT
(and grossly exceeding the bounds of their charter in the process)

> How about some lemonade?  An Internet draft that says 
> something new about NATs would be a lot more helpful than 
> rehashing the same old arguments.

for one attempt to make lemonade, see RFC 3056.
for another, see draft-ietf-ngtrans-shipworm-08.txt
for another, see draft-moore-nat-tolerance-recommendations-00.txt
(it's expired - look in http://www.cs.utk.edu/~moore/I-D/ )

but looking for a way to magically turn NATs into something that works
well that doesn't require both significant infrastructure investment and
significant changes to the endpoints and apps is tantamount to wishing
for magic pixie dust.

Keith

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Michael Thomas]

Iljitsch van Beijnum writes:
 > On woensdag, jun 18, 2003, at 21:17 Europe/Amsterdam, Bob Braden wrote:
 > 
 > > Since 1980 we have believed that universal connectivity was one of the
 > > great achievements of the Internet design.  Today, one must
 > > unfortunately question whether universal connectivity can be sustained
 > > (or is even the right goal) in a networking environment without
 > > universal trust.
 > 
 > I think we can safely say that 99.99% of all systems that run IP don't 
 > want to talk to 99.99% of all systems that run IP. For most people, 
 > with a network this large, universal connectivity isn't a goal but a 
 > threat. But this shouldn't be confused with universal addressability 
 > being undesirable, because this only gets more important as the size of 
 > the network increases.

Voice challenges this assumption to a very large
degree. In fact, I not only want access to 99.99%
of the other nodes on the net willing to speak
RTP, but I most certainly don't want to be forced
to go through some forced eavesdrop-tapping,
terrorist-witchhunting intermediary that is
subject to the whims of certain fanatics from
Missouri and Utah who are convinced that peetopee
is the spawn of Satan.

 Mike

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Eric Rescorla]

Keith Moore <[EMAIL PROTECTED]> writes:
> > I don't know enough about how you're doing your distributing computing
> > to have an opinion, but as for the other two... In my experience,
> > IT managers are pretty unhappy punching holes in their firewalls
> > for incoming SIP and IPsec, whether they run NAT or not.
> 
> In my experience, IT managers are generally pretty unhappy changing
> anything to support their users.  People who actually use the computers
> or the network are regarded as a nuisance.
Exactly. So, why do you it's NATs that are the cause of users
not getting the things they want, as opposed to the usual IT
manager behavior.

> > The bottom line here is what economists call "revealed preference".
> 
> Maybe "revealed ignorance" would be a better term.  Though I prefer
> "unintended consequence".
Huh? The IT managers could not use NAT if they wanted. What
evidence do you have that they consider them a bad tradeoff?

-Ekr



-- 
[Eric Rescorla   [EMAIL PROTECTED]
http://www.rtfm.com/

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Keith Moore]

> We lost our chance to avoid NAT's when variable length addresses were
> removed from TCPv2.5 (IIRC the version number correctly). 

or maybe when IAB was shot down after Kobe :)

> NAT's are here, like it or not, and the only question is how to make
> lemonade out of them. 

see my other comment about magic pixie dust.

the way to fix NATs is to obsolete them.  IPv6 is the best shot we have
at that.

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Eric Rescorla]

Melinda Shore <[EMAIL PROTECTED]> writes:

> > What applications that people want to run--and the IT managers would
> > want to enable--are actually inhibited by NAT? It seems to me that
> > most of the applications inconvenienced by NAT are ones that IT
> > managers would want to screen off anyway.
> 
> Not really.  For example, ftp as originally defined doesn't
> work through NATs, and no standard VoIP or multimedia
> conferencing protocol works through NAT.  
None of these things worked real well through firewalls either,
which is sort of my point.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]
http://www.rtfm.com/

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Keith Moore]

> > In my experience, IT managers are generally pretty unhappy changing
> > anything to support their users.  People who actually use the
> > computers or the network are regarded as a nuisance.
>
> Exactly. So, why do you it's NATs that are the cause of users
> not getting the things they want, as opposed to the usual IT
> manager behavior.

good point.  maybe the very reason that IT managers like NATs is that
they make the users' lives more difficult, and they provide job security
for IT managers who have to sort out NAT problems just so that things
can work at all.  but from the ones I've talked to, some combination of
ignorance, brainwashing, and stupidity seems more likely.

Keith
 

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Eric Rescorla]

Keith Moore <[EMAIL PROTECTED]> writes:

> > > In my experience, IT managers are generally pretty unhappy changing
> > > anything to support their users.  People who actually use the
> > > computers or the network are regarded as a nuisance.
> >
> > Exactly. So, why do you it's NATs that are the cause of users
> > not getting the things they want, as opposed to the usual IT
> > manager behavior.
> 
> good point.  maybe the very reason that IT managers like NATs is that
> they make the users' lives more difficult, and they provide job security
> for IT managers who have to sort out NAT problems just so that things
> can work at all.  but from the ones I've talked to, some combination of
> ignorance, brainwashing, and stupidity seems more likely.

One of the things I've always find endearing about IETFers is their
utter confidence that whenever the world disagrees with them about the
value of some technical approach, it must be because everyone else in
the world is stupid.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]
   Web Log: http://www.rtfm.com/movabletype

RE: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Paul Hoffman / IMC]

At 1:31 PM -0700 6/18/03, Vach Kompella wrote:
 > - the IETF's track record for this work so far is quite poor

That's not a problem of the ppvpn group only.  It is a problem of the IETF.
Generally agree.

I don't need to refresh your memory about IPSec, do I?  SKIP, Skeme, Oakley,
IKE.  AH or ESP with auth?  5 years of bloody fighting.
I'm not sure how to argue with the statement "the IETF has done a 
horrible job with a similar working group, so we want our working 
group in the IETF".

First off, I agree with you about the IPsec WG, and think it is a 
very good indicator of what the IETF does poorly, particularly in the 
area of focus. (Hint: look at the number of WG Internet Drafts there 
are right now in IPsec that no one is working on.) The problems in 
the IPsec WG and others are typical of the problems of the WGs that 
are working on trusted VPN technologies.

It's wherever the action is that the political jostling for position 
is the most
prominent.  That's also where the leadership needs to be strong and 
participants
need to have a "nose to the grindstone" attitude.  That's hardly an indication
that the work should not be chartered or worked upon.
Er, yes it is. There is no indication that we will do a better job 
than the terrible job we are doing now. What you propose sounds like 
"we're terrible parents for our six children and barely have enough 
time to pay attention to them, but maybe we'll be better with the 
seventh."

 > We have not shown any ability to create standards in this area with
 due speed or predictability. We have not shown the good judgement
 needed to limit the scope of the work we do. (Look at the number of
 L2VPN-based Working Group drafts in PWE3 and PPVPN, much less the
 large number of non-WG documents being actively discussed.
Do you think the new L2VPN charter addresses these concerns of scoping?  How
about the timelines?  Basically, it's going to be a WG issue, chairs and
participants, to finish the WG charter items first.
Why do you think that the re-chartered WG will have any more luck 
with these than the current one? There are a zillion hardware vendors 
and service providers who have reasons to want the dozens of 
documents that are in the current WGs, and it takes very little 
effort on their part to promote their views. The IETF structure does 
poorly in such an environment; maybe a different standards body would 
do better.

 > The IETF understands the need for layer 2 technologies for OAM much
 better than we understand the Internet customer's need (or even
 concern) for layer 2 transport of their IP packets. This is because
 we have a tighter relationship with operators than we do with
 Internet users, and because Internet users generally could care less
 about how their ISPs move their traffic as long as they meet the
 service level agreements. The ISPs would love to have better
 cross-vendor interop for the L2VPN technologies, but so far the
 vendors haven't had time to think about that because they have been
 overloaded with the literally dozens of flavors that are being
 discussed in the IETF.
Are you talking PWE3 or L2VPN?
Yes. There is a significant amount of spillage between the two.

The gazillion drafts is in PWE3.  The interop issues are localized 
to the drafts
with contention, silly issues of where bits should go.

There are 16 pseudowire types:
   0x0001   Frame Relay DLCI
   0x0002   ATM AAL5 SDU VCC transport
   0x0003   ATM transparent cell transport
   0x0004   Ethernet Tagged Mode
   0x0005   Ethernet
   0x0006   HDLC
   0x0007   PPP
   0x0008   SONET/SDH Circuit Emulation Service Over MPLS (CEM) [8]
   0x0009   ATM n-to-one VCC cell transport
   0x000A   ATM n-to-one VPC cell transport
   0x000B   IP Layer2 Transport
   0x000C   ATM one-to-one VCC Cell Mode
   0x000D   ATM one-to-one VPC Cell Mode
   0x000E   ATM AAL5 PDU VCC transport
   0x000F   Frame-Relay Port mode
   0x0010   SONET/SDH Circuit Emulation over Packet (CEP)
At least half of these are and have been interoperable.  It is the harder (and
more arcane, IMHO) PW types that people are having a hard time coming to some
sort of compromise.
And why should the IETF care at all about these? There are other fora 
for layer-2 interworking.

BTW, I'm glad to see you have a healthier respect for providers than 
Kurtis who
claims that "most of these providers have bought what their vendor 
told them to
buy."
He and I might both be right. In my talks with service providers, I 
find that many of them who want to expand their presence in, or just 
get into, the "IP VPN" market look at what hardware they have on hand 
in their core (they certainly can't buy any significant new hardware 
these days) and base their decision on the layer-2 technologies on 
that. Usually, the customers don't know or care. If the customers 
care, they only care enough to ask "are you 

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Keith Moore]

> One of the things I've always find endearing about IETFers is their
> utter confidence that whenever the world disagrees with them about the
> value of some technical approach, it must be because everyone else in
> the world is stupid.

hey, not everyone else is an IT manager :)

investing in nat boxes is a lot like investing in lottery tickets.
but for some reason both sell well...

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Paul Vixie]

[EMAIL PROTECTED] (Michael Thomas) writes:

> Voice challenges this assumption to a very large
> degree. In fact, I not only want access to 99.99%
> of the other nodes on the net willing to speak RTP ...

actually i think you probably don't, or rather, won't.

telemarketing by robot is illegal in some places but is
widely used to detect fax machines or voice-answered
lines for later use by other robots or by humans.  one
of the cost components for this kind of activity today
is a room full of CTI hardware and a DS1 (or better) and
a willingness to buy blocks of long distance minutes.

assuming VoIP takes off, the costs of robotic telemarketing
are going to go way way down.  in particular, it may become
popular to sweep the E164.ARPA address space looking for
endpoints, then sweep the resulting RTP endpoints looking
for live reachable instruments like humans and fax machines.

it's safe to say that the same people who call you at home
during dinner to sell you chemicals for your septic tank
are going to team up with the same people who send you spam
or who do "e-mail appending" or who spam your fax machine
with vacation offers...

...and that your RTP instrument will have to be one of the
most violently over-firewalled devices on your network in
order to remain useful for its intended (by you that is)
purpose.

maybe i should get back into the blackhole business, but for
VoIP this time, since it'll be a HGE market.
-- 
Paul Vixie

RE: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Vernon Schryver]

> From: Paul Hoffman / IMC <[EMAIL PROTECTED]>

> ...
> Why do you think that the re-chartered WG will have any more luck 
> with these than the current one? There are a zillion hardware vendors 
> and service providers who have reasons to want the dozens of 
> documents that are in the current WGs, and it takes very little 
> effort on their part to promote their views. The IETF structure does 
> poorly in such an environment; maybe a different standards body would 
> do better.

> ...
> And why should the IETF care at all about these? There are other fora 
> for layer-2 interworking.

That's an interesting pair of thoughts.  The obvious guess is that
interested parties are happy with the bad job the IETF has been doing and
are doing a little forum shopping.  In the areas I've been watching (which
do not include IPSEC, DNSSEC, or VPNs), the bad jobs consist of rubber
stamping ideas whose lameness is exceeded only by their complete lack of
interest and any trace of originality.  It's amazing how many people feel
compelled to take a well established idea with many ancient implementations
and write an RFC standardizing a redundant, unnecessary version elsewhere.
(Is that also the deal with this tunnel stuff?)

I suspect the IESG is overtaxed, overextended, and doesn't have enough
thumbs to stick in all of holes in the dikes holding back the floods
of wonderful ideas from marketing departments and junior, not-quite
engineers with ambitions in marketing.

A modest proposal:  Limit the supply of RFC (not to mention BCP)
numbers.  If only 50 RFC numbers were available for the next 12 months,
there would be an incentive for competent people to stick their necks
out and stomp on some of the nonsense to ensure that things that need
consideration would get it.  I doubt the IETF could produce 10 good
RFCs in the next 12 months, so 50 numbers would be generous.

Without that, an equivalent of the IEEE PAR, or some other effective
mechanism, the IETF is going to suffer the fate dictated by Gresham's
Law of any mint that fails to control its output.


Vernon Schryver[EMAIL PROTECTED]

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Stephen Sprunk]

Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]>
> For any particular application and group of users, and in order to
> switch over seamlessly, it is necessary that all servers become dual
> stack, then clients can switch (without the need to run dual stack) and
> after that the servers can drop IPv4.

That is one scenario; there are others.

> And for peer-to-peer, _everyone_ is a server so _everyone_ has to
> run dual stack before it's possible to drop IPv4.

Out of curiosity I sniffed my own P2P applications and found that over 50%
of the hosts my client tried to contact weren't available, presumably due to
NATs, firewalls, or other connectivity impediments.  In spite of this
problem, the P2P networks work well enough nobody cares about the problem.

I conclude, therefore, that as long as a sizable minority of P2P users are
dual stack, the majority can safely speak only v4 or only v6.

S

Stephen Sprunk "God does not play dice."  --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSSdice at every possible opportunity." --Stephen Hawking

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[George Michaelson]

Just because I *have* a NAT box to use at home doesn't mean I *like* NAT.

I expect to find deployment of IPv6 at home challenging, in part because I've
already spent my 'five-year-plan' funds on networks for home. 

Its the same road-trap digital TV is caught in: people do not rush out and buy
even small communications/technology investments as throw-away devices. TV sets
last for 5-10 years. Hi-Fi sets last even longer. $5 low-fi radios last almost
forever, sliding down the hierarchy from the living room, to the kitchen, to the
garage. 

I expect my Nat box to last another two or three years. I do not expect the
vendor to be able to ship an IPv6 ready image for this box. Therefore I will
have to convince the 'house funding committee' to let me replace this box before
its real end-of-life window. That is hard, set against the cost of painting the
house, or urgent repairs to the steps, or replacing the VHS recorder by a DVD
player.

If a massive volume of IPv6 ready NAT or other boxes arrived on the market right
now, I do not think the take-up would be explosive. The early adopters might buy
in but it would require the *default* configuration to new players to be fully
V6 enabled, and even then the rollover time in the home segment would be
measured in years.

NAT is irrelevant to this IPv6 deployment thing. its neither an obstruction nor
a benefit. The business cycle and non-financial motivations about spending and
lifestyle are just as relevant, if not more so.

If my home network supplier let me have multiple IPv4 DHCP addresses that
were routable behind the cable box, I would probably still keep this NAT box,
even if I did turn off NAT. 

I still have my recordplayer connected to my Hi-Fi even if I don't play records
much.

 cheers

-George

Re: Last Call: LDP DoD Graceful Restart to Draft Standard

[Alex Zinin]

Adrian, folks-

 I opened a ticket with the secretariat about this error a couple
 of days ago:
 
  [iesg-secretary #8150] Wrong Document Action: draft-ietf-mpls-ldp-dod-restart-00.txt

 I will ping them again.

-- 
Alex
http://www.psg.com/~zinin/

Wednesday, June 18, 2003, 11:56:51 AM, Adrian Farrel wrote:
> Did anyone decide there was an error here, or is this draft really in IETF last
> call?

> Thanks
> Adrian
> - Original Message -
> From: "Adrian Farrel" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Friday, June 13, 2003 5:23 PM
> Subject: Re: Last Call: LDP DoD Graceful Restart to Draft Standard


>> With respect, this draft doesn't appear to have been through WG last call
>> (unless I was sleeping, but I can't find any reference in the mail archive).
>>
>> It was only published as a WG draft on 5/7/2003 (despite carrying a date of
>> February 2003).
>>
>> While I support the draft, I would like to see it discussed on the mailing
> list
>> and go through WG last call.
>>
>> Thanks,
>> Adrian
>>
>> - Original Message -
>> From: "The IESG" <[EMAIL PROTECTED]>
>> To: 
>> Cc: <[EMAIL PROTECTED]>
>> Sent: Friday, June 13, 2003 1:59 PM
>> Subject: Last Call: LDP DoD Graceful Restart to Draft Standard
>>
>>
>> > ---
>> > The IESG has received a request from Multiprotocol Label Switching to
>> > consider the following Internet-Draft(s) as Draft Standard.
>> > o Multiprotocol Label Switching (MPLS): LDP DoD Graceful Restart
>> >   
>> >   Draft Standard
>> >
>> >
>> > The IESG plans to make a decision in the next few weeks, and solicits
>> > final comments on this action.  Please send any comments to the
>> > [EMAIL PROTECTED] or [EMAIL PROTECTED] mailing lists by .
>> >
>> > Files can be obtained via
>> > http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-dod-restart-00.txt
>> >
>>
>>

Re: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Scott W Brim]

On Wed, Jun 18, 2003 03:31:56PM -0400, Melinda Shore allegedly wrote:
> > The IETF does continue to have an emphasis on connectionless,
> > packet-oriented delivery.  That's our fundamental architecture,
> > without question.  In the meantime there are customers who want to
> > transition to c, p-o d but need mechanisms for doing so.
> 
> Personally I'd find this proposal more compelling if it were being
> presented as being oriented towards transitional mechanisms.  

You're right, that doesn't get mentioned.  However, many providers see
it that way.  (Admittedly there are some who don't.)

> We're seeing circuit-y proposals show up in other working groups and
> I'm concerned that these reflect a shift in basic assumptions about
> the characteristics of the underlying network, at least among a
> non-trivial number of participants.  

People who can't see beyond the circuit approach shouldn't be given
responsibility for Internet architectural thinking, and right now
fundamental architectural thinking is what we need more than anything.

.swb

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[Eric A. Hall]

on 6/18/2003 5:37 PM Keith Moore wrote:

> you're simply wrong about that, at least for anything resembling
> today's NATs.  except for a shortage of IPv4 addresses, NATs would not
> be needed at all.

...and a routing grid that could handle a squared table size. No use in
opening allocations to everybody that can justify ~/29 if filters are
still going to be dropping everything after /20.

-- 
Eric A. Hallhttp://www.ehsco.com/
Internet Core Protocols  http://www.oreilly.com/catalog/coreprot/

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Richard Shockey]

At 12:07 AM 6/19/2003 +, Paul Vixie wrote:

[EMAIL PROTECTED] (Michael Thomas) writes:

> Voice challenges this assumption to a very large
> degree. In fact, I not only want access to 99.99%
> of the other nodes on the net willing to speak RTP ...
actually i think you probably don't, or rather, won't.

telemarketing by robot is illegal in some places but is
widely used to detect fax machines or voice-answered
lines for later use by other robots or by humans.  one
of the cost components for this kind of activity today
is a room full of CTI hardware and a DS1 (or better) and
a willingness to buy blocks of long distance minutes.
Which BTW come July 1 becomes illegal in the US with the implementation of 
the Federal Trade Commission Do Not Call list.

http://www.ftc.gov/bcp/conline/edcams/donotcall/index.html


assuming VoIP takes off, the costs of robotic telemarketing
are going to go way way down.  in particular, it may become
popular to sweep the E164.ARPA address space looking for
endpoints, then sweep the resulting RTP endpoints looking
for live reachable instruments like humans and fax machines.
I'm personally asked this all the time since I co-chair the ENUM WG. I 
think there is going to be some differences here..

A. The way the FTC DNC law was written it is transport neutral. Some of us 
are confident we can apply the law directly to ENUM enabled VoIP.

People forget that the TCPA Telephone Consumer Protection Act in the US and 
the anti junk fax laws were generally effective if a private cause of 
action was permitted. That BTW is the central issue now being debated in 
Congress in the mark up of the Burns-Wyden bill tomorrow.

http://www.spamlaws.com/federal/108s877.html

I would have loved to be able to insert into the bill a provision to make 
RFC 3261 header spoofing illegal as well.

B. The real key here in the protection of VoIP will be my ability to 
control my SIP proxy at the edge as a policy control mechanism.

Personally I would have preferred Charlie Schumers bill which would have 
had a do not spam list but it seems its not going to make it this session.

http://www.spamlaws.com/federal/108s1231.html


...and that your RTP instrument will have to be one of the
most violently over-firewalled devices on your network in
order to remain useful for its intended (by you that is)
purpose.
maybe i should get back into the blackhole business, but for
VoIP this time, since it'll be a HGE market.
The Feds will beat you to market on this one...

--
Paul Vixie


>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 703.593.2683,  Fax: +1 815.333.1237
 or 
  ; 
<

RE: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Vach Kompella]

Paul,

>
>
> At 1:31 PM -0700 6/18/03, Vach Kompella wrote:
>
> I'm not sure how to argue with the statement "the IETF has done a
> horrible job with a similar working group, so we want our working
> group in the IETF".

Well, how about, we can't agree on IPv6 numbering schemes, so let's find another
standards org to fix that problem.  We can't decide whether site-local is good
for IPv6 or not, so let's find another standards org. ...  What kind of
unmitigated disaster would IKE have been if we had just punted it over to, say,
the ITU?

Alternatively, we can own up that it is OUR problem, i.e., the IETF, and if we
want a solution, we will create one here.  E.g., I'm happier having IPSec than
no security.



> Er, yes it is. There is no indication that we will do a better job
> than the terrible job we are doing now. What you propose sounds like
> "we're terrible parents for our six children and barely have enough
> time to pay attention to them, but maybe we'll be better with the
> seventh."

No, it's not.  Having a seventh child is an option.  No-one is clamoring for
that seventh child.

It's more like having seven kids and not having enough money for 7 holiday
gifts, and so declaring that one of the kids should go to a foster parent.

> >
> >Do you think the new L2VPN charter addresses these concerns of scoping?  How
> >about the timelines?  Basically, it's going to be a WG issue, chairs and
> >participants, to finish the WG charter items first.
>
> Why do you think that the re-chartered WG will have any more luck
> with these than the current one? There are a zillion hardware vendors
> and service providers who have reasons to want the dozens of
> documents that are in the current WGs, and it takes very little
> effort on their part to promote their views. The IETF structure does
> poorly in such an environment; maybe a different standards body would
> do better.

I thought that Moskowitz and Tso did a pretty good job of not letting new stuff
into IPSec towards the end.

Is there no perceptible difference between the rather open-ended ppvpn charter
and the rather more focused l2vpn/l3vpn charters?  Maybe that was a leading
question :-)

I have rather studiously avoided submitting three new drafts that may address
issues that some folks have raised concerns about.  As usual, thinking up new
thoughts and solutions is a lot more fun than finishing the job at hand.  That's
where individual submissions should stay until the current plate is cleaned up.
No time in the agenda, nothing but mailing list and individual submission
opportunity.

> >
> >Are you talking PWE3 or L2VPN?
>
> Yes. There is a significant amount of spillage between the two.
>

Not really.

> >
> >There are 16 pseudowire types:
> >0x0001   Frame Relay DLCI
> >0x0002   ATM AAL5 SDU VCC transport
> >0x0003   ATM transparent cell transport
> >0x0004   Ethernet Tagged Mode
> >0x0005   Ethernet
> >0x0006   HDLC
> >0x0007   PPP
> >0x0008   SONET/SDH Circuit Emulation Service Over MPLS (CEM) [8]
> >0x0009   ATM n-to-one VCC cell transport
> >0x000A   ATM n-to-one VPC cell transport
> >0x000B   IP Layer2 Transport
> >0x000C   ATM one-to-one VCC Cell Mode
> >0x000D   ATM one-to-one VPC Cell Mode
> >0x000E   ATM AAL5 PDU VCC transport
> >0x000F   Frame-Relay Port mode
> >0x0010   SONET/SDH Circuit Emulation over Packet (CEP)
> >
> >At least half of these are and have been interoperable.  It is the
> harder (and
> >more arcane, IMHO) PW types that people are having a hard time coming to some
> >sort of compromise.
>
> And why should the IETF care at all about these? There are other fora
> for layer-2 interworking.

OK.  Which of those arcane PWs is relevant to ppvpn?  The ones ppvpn is
concerned with are pretty well established and interoperable.

>
> --Paul Hoffman, Director
> --Internet Mail Consortium
>

-Vach

test mail

[Soohong Daniel Park]

sorry

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Paul Vixie]

> Which BTW come July 1 becomes illegal in the US with the implementation of
> the Federal Trade Commission Do Not Call list.

which country's "federal" do you mean?

> http://www.ftc.gov/bcp/conline/edcams/donotcall/index.html

oh, that one.  i guess that means the function will have to move offshore.
THAT'll sure teach those spammers a lesson.

Re: myth of the great transition

[Vernon Schryver]

> From: Paul Vixie <[EMAIL PROTECTED]>

> ...
> > http://www.ftc.gov/bcp/conline/edcams/donotcall/index.html
>
> oh, that one.  i guess that means the function will have to move offshore.
> THAT'll sure teach those spammers a lesson.

The U.S. FCC wielded the TCPA with reasonable effect against the
(supposedly?) English or Canadian 21st Century "1-900 vote" junk
fax blasters.  See http://www.fcc.gov/eb/News_Releases/nrtcf.html
and http://www.fcc.gov/eb/News_Releases/nr21cen1.html

Related to what you wrote a little while ago, blackhole routes are
easier to deploy against overseas senders of junk IP packets (for most
localized notions of "overseas") than nearby spammers.  Do you get
much spam direct from China or Korea?

But what does this have to L2VPN or the IETF?


Vernon Schryver[EMAIL PROTECTED]

Re: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Eric Rosen]

People need to understand that the purpose of the Pseudowire stuff (PWE3) is
to enable service providers to  offer existing services over IP networks, so
that they can convert their backbones to IP without first requiring that all
their  customers change  their  access equipment.   Producing the  protocols
needed to enable  migration from legacy networks to IP  networks seems to me
to  be quite in  the mainstream  of IETF.   The technical  issues, involving
creating tunnels, multiplexing  sessions through tunnels, performing service
emulation at the  session endpoints, are all issues that  the IETF has taken
up in the past, there is nothing radically different going on here. 

(To those  who think that other  standards organizations can  do this better,
well, representatives from those other organizations feel free to drop in on
the WGs  in question, so  we are familiar  with their level of  expertise on
IP.   Let's just  say that  if we  want to  aid in  the migration  of legacy
networks to IP, these other organizations are not what we would want to rely
on.) 

One can think of the VPWS work  in L2VPN as taking the PWE3 stuff and adding
some IP-based auto-discovery  mechanisms to facilitate provisioning.  Again,
this isn't out of line with what the IETF typically does. 

The VPLS work is  more difficult to position within the IETF,  as it is hard
to  avoid a lot  of stuff  that overlaps  with IEEE  (a standards  org which
really is  worthy of  respect, unlike some  others), and  extending ethernet
over an IP network  is arguably a bad idea.  On the  other hand, the purpose
is the  same as  indicated above; service  providers can migrate  from their
Q-in-Q  ethernet networks  to  IP networks,  without  first requiring  their
customers to switch from an ethernet service to an IP service.  

RE: NATs are NOT Firewalls

[Michel Py]

Eric,

I agree with most of your post but there is something that you have not
grasped IMHO.

It is true that "dissimulating" the private (RFC1918?) address does not
achieve much in terms of security: in order to access:
http://arneill-py.sacramento.ca.us/ipv6mh/ you do not need to know nor
care that the IP address of the web server is 192.168.1.4. Knowing it
might provide limited help way farther down the hacking process though
and is likely to be leaked in things such as SMTP headers anyway.

However, if you are correct in saying that NAT != firewall, you are
mostly _not_ correct in saying that a NATs are not firewalls, as most
NAT boxes indeed are NAT+PAT boxes and {NAT != firewall} applies to
non-PAT things such as one-to-one static NAT (not overloaded) or subnet
natting.
Refrigerator = Frigidaire
Copy machine = Xerox
NAT box  = Linksys

> Eric Tomson wrote:
> 2.circuit level gateways (work mainly at session layer, by
> identifying flows of data and established connections),
> A more advanced device, able to identify "conversations",
> "sessions", is a bit more advanced firewall of type 2.

By your own definition a NAT+PAT box is a type 2 firewall or circuit
level gateway. A pure NAT device (rare) does not care about flows but a
NAT+PAT box (very common) does and maintains hard state about them as
show below:

cisco3640#sh ip nat tr
Pro Inside globalInside local  Outside local  Outside
global
udp 209.233.126.65:1060  192.168.1.4:1060  206.13.31.12:53
206.13.31.12:53
tcp 209.233.126.65:1263  192.168.1.7:1263  198.133.219.25:80
198.133.219.25:80
tcp 209.233.126.65:25192.168.1.4:25------
tcp 209.233.126.65:80192.168.1.4:80------

Linksys/Netgear/misc home/soho NAT boxes have similar mechanisms. The
first two are originated-from-inside dynamic flows, the last two are
statically punched holes. Note that TCP flows are torn down as soon as
the TCP connection is terminated where UDP flows are torn down with a
timeout; on a Cisco 'show ip nat trans verbose' will show the timeouts.

This hard state is why NAT+PAT boxes have often been compared to
firewalls because _one_ of the features of firewalls is to build this
hard state that allows only return traffic related to traffic originated
from the inside (unless a hole is punched). The security brought by the
NAT+PAT process comes from this hard state; no entry in the translation
table, no traffic. A firewall (or a reflective access-list for Cisco
geeks) builds hard state the same way except that of course it does not
change the address.


> NATs [...] won't control the traffic

This is incorrect for most NAT boxes. Although it is true that the main
two purposes of NAT are saving IPs (one-to-many NAT) and ease
renumbering, it is equally true that if there is no open flow originated
from the inside (or hole punched administratively), a NAT+PAT _DOES_ by
default block traffic originated from the outside, which is a
significant part of why people buy firewalls in the first place: Allow
users to surf but don't open anything except a few ports to a few IPs in
the other direction.

In other words, a NAT+PAT device blocks by default all traffic except
statically punched holes and transient return traffic related to a flow
opened from the inside (specific to a pair of IP addresses and a pair of
ports).

This circuit-level gateway feature is not enough security and must be
complemented with access-lists and stateful inspection but it's one of
the third major building blocks of a firewall. But that's for network
geeks; the sad truth is that when the network admin is lame (grandma or
Joe's Pizza) a windoze 9x PC is safer behind a Linksys than connected
directly to the cable modem.

As of myself I would not call a firewall any device that does not have
stateful packet inspection (free hint to IPv6 vendors ;-)

But by your own definition a NAT+PAT box is a firewall of type 2. Add to
this that when combined with RFC1918 they bring very easy renumbering as
only the outside address has to be changed and you'll understand why
there are so many of them around.

For the record, and since this thread started with IPv6, I am totally
against IPv6 NAT. With IPv4, all we have left at this time are lemons so
there's nothing wrong in making lemonade with them even if we prefer
beer. Although it is part of the job, IPv4 NAT is a royal pain in the
butt that I would gladly live without. But for IPv6 it is not too late.
If the end-to-end principle is a dogma it's not only because IETFers
like dogmas but mostly because NAT plain stinks.

Michel.

RE: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Paul Hoffman / IMC]

At 6:43 PM -0700 6/18/03, Vach Kompella wrote:
 > I'm not sure how to argue with the statement "the IETF has done a
 horrible job with a similar working group, so we want our working
 group in the IETF".
Well, how about, we can't agree on IPv6 numbering schemes, so let's 
find another
standards org to fix that problem. We can't decide whether site-local is good
for IPv6 or not, so let's find another standards org.
IPv6 is an IP technology. We are supposed to know how to make it 
work. L2VPNs (and half of the interesting parts of 2547bis L2VPNs) 
are outside the scope of our expertise.

 ...  What kind of
unmitigated disaster would IKE have been if we had just punted it 
over to, say,
the ITU?
Worse, no doubt. But I'm not proposing to send the L2VPN work to an 
organization with no expertise or credibility in the L2 area.

Alternatively, we can own up that it is OUR problem, i.e., the IETF, and if we
want a solution, we will create one here.
If we decide that "the problem" is one in our realm, I fully agree. 
But transporting layer 2 stuff over IP is not a problem that affects 
the Internet. It is a problem for the service providers marketing 
departments. The past three yeas have proven that service providers 
can satisfy their customers needs with L3VPNs, with 
somewhat-interoperable L2VPNs, with non-interoperable L2VPNs, and 
with just plain layer 2 circuits. What is "the problem" that the IETF 
needs to standardize?

  E.g., I'm happier having IPSec than
no security.
Of course. But we'd both be happier if IPsec worked better as a VPN 
technology, and applications folks would be happier if it worked 
better as an application security technology.

--Paul Hoffman, Director
--Internet Mail Consortium

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Valdis . Kletnieks]

On Wed, 18 Jun 2003 16:06:08 PDT, Eric Rescorla said:
> Melinda Shore <[EMAIL PROTECTED]> writes:

> > Not really.  For example, ftp as originally defined doesn't
> > work through NATs, and no standard VoIP or multimedia
> > conferencing protocol works through NAT.  
> None of these things worked real well through firewalls either,
> which is sort of my point.

There's a *crucial* distinction here:

If it doesn't work through a firewall, it's because the firewall is doing
what you ASKED it to do - block certain classes of connections.

If it doesn't work through a NAT, it's because the NAT is FAILING to do what
you asked it to do - allow transparent connections from boxes behind the NAT.

Unless of course you're deploying NAT for some reason *OTHER* than
transparent connections?  Are you trying to get your money's worth because
you paid for the extra-deluxe "works most of the time but breaks some apps"
version?

Or is the only reason you have NAT at all because you bought some vendor's
"connection appliance in a box" that proceeded to NAT you regardless of your
desires?


pgp0.pgp
Description: PGP signature

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Eric Rescorla]

[EMAIL PROTECTED] writes:

> On Wed, 18 Jun 2003 16:06:08 PDT, Eric Rescorla said:
> > Melinda Shore <[EMAIL PROTECTED]> writes:
> 
> > > Not really.  For example, ftp as originally defined doesn't
> > > work through NATs, and no standard VoIP or multimedia
> > > conferencing protocol works through NAT.  
> > None of these things worked real well through firewalls either,
> > which is sort of my point.
> 
> There's a *crucial* distinction here:
> 
> If it doesn't work through a firewall, it's because the firewall is doing
> what you ASKED it to do - block certain classes of connections.
> 
> If it doesn't work through a NAT, it's because the NAT is FAILING to do what
> you asked it to do - allow transparent connections from boxes behind the NAT.
> 
> Unless of course you're deploying NAT for some reason *OTHER* than
> transparent connections?  Are you trying to get your money's worth because
> you paid for the extra-deluxe "works most of the time but breaks some apps"
> version?
This seems to me like a false dichotomy. If I were deploying a NAT 
(which I didn't) there would be certain things I would care about
and others I didn't. If I'm already firewalling off these services,
why should I care if NAT blocks them?

> Or is the only reason you have NAT at all because you bought some vendor's
> "connection appliance in a box" that proceeded to NAT you regardless of your
> desires?
Why is it so hard for people here to believe that customers might
actually know what they want, even if you don't happen to think
it's a good idea?

-Ekr


-- 
[Eric Rescorla   [EMAIL PROTECTED]
http://www.rtfm.com/

Re: myth of the great transition

[S Woodside]

On Wednesday, June 18, 2003, at 03:39  PM, Keith Moore wrote:

I think it would be more accurate to say that a NAT contravenes
the basic Internet prnciple of universal connectivity.
expecting the network
to isolate insecure hosts from untrustworthy attackers, or more
generally, to enforce policy about what kinds of content are
permitted to pass, has always been a stretch.
So where do firewalls fit into your picture? Do they represent for the 
network or for the hosts?

simon

--
www.simonwoodside.com -- 99% Devil, 1% Angel

RE: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Michel Py]

Valdis,

> Valdis Kletnieks wrote:
> If it doesn't work through a firewall, it's because the
> firewall is doing what you ASKED it to do - block certain
> classes of connections.

I'm sorry but it is nothing near being that simple. Although if it does
not work through a firewall, it MAYBE because the firewall does block a
class of traffic (more likely because someone forgot to punch the right
hole), there are _plenty_ of other reasons why it does not work through
a firewall, one of the top ones being asymmetric traffic when there is
more than one exit point and the firewall hard state not being
distributed.
 
> Melinda Shore <[EMAIL PROTECTED]> writes:
> None of these things worked real well through firewalls
> either, which is sort of my point.

Melinda's point is perfectly valid. To quote Brian Carpenter, state is
evil and distributed state is worse.
Unfortunately, they are part of the network engineer's life.

Michel.

Re: NATs are NOT Firewalls

[S Woodside]

On Wednesday, June 18, 2003, at 06:28  PM, Tomson Eric ((Yahoo.fr)) 
wrote:

Now, the fact that masking the internal addresses to the external
world - so that internal hosts can initiate traffic to the outside, 
but no
external host can initiate traffic to the inside - brings some basic
security, is an interesting corollary, but not the primary objective 
of a
NAT.
Is this just security through obscurity, or something better?

simon

--
www.simonwoodside.com -- 99% Devil, 1% Angel

Re: myth of the great transition

[S Woodside]

I wonder if NAT is to ietf discussions as Nazis was
to Usenet discussions.
You mean NATzis?

simon

^_^

--
www.simonwoodside.com -- 99% Devil, 1% Angel

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Valdis . Kletnieks]

On Wed, 18 Jun 2003 21:30:35 PDT, Eric Rescorla said:

> This seems to me like a false dichotomy. If I were deploying a NAT 
> (which I didn't) there would be certain things I would care about
> and others I didn't. If I'm already firewalling off these services,
> why should I care if NAT blocks them?

So it's OK for NAT to break any application that *you* don't want to
let through *your* firewall anyhow.

What's wrong with this picture?  Well.. Sure, if you currently only allow
3 ports through your firewall anyhow, and those 3 applications happen to
be NAT-tolerant, it's probably no impact on YOUR site.

Of course, if you *ever* encounter an application that your site wants to
allow through the firewall, but you discover that you STILL can't deploy it
because NAT breaks it, you'll be wanting some mayonnaise to make that crow
sandwich go down more easily.

You're missing the point that when a firewall breaks things, it's doing
its job.  When a NAT breaks things, it's failing to do its job.

Now let's say a firewall is a pair of suspenders, and a NAT is a belt.  This
makes your position:

"I don't care that my belt unzips my trousers every time I go through a
revolving door, because I'm never in a situation where failure of my
suspenders would be an embarassment".

As Randy Bush says: "I invite my competitors to design their networks this way".

>> Or is the only reason you have NAT at all because you bought some vendor's
>> "connection appliance in a box" that proceeded to NAT you regardless of your
>> desires?
> Why is it so hard for people here to believe that customers might
> actually know what they want, even if you don't happen to think
> it's a good idea?

Tell you what - you round up all the big domains that actually have a clue
about what they want, and who understand the distinction between a firewall and
a NAT (even if they are in the same box), and I'll round up all the users who
are scratching their heads because they have a cablemodem or an ADSL modem
(either ISP-provided or off the shelf at Walmart) that is an all-in-one modem/
router/firewall/NAT, and some stuff Just Does Not Work.

And unfortunately, a lot of the Just Does Not Work stuff are applications
like H.323 and VOIP that Joe Sixpack actually *might* be interested in.



pgp0.pgp
Description: PGP signature

Re: myth of the great transition (was US Defense Departmentformally adopts IPv6)

[Einar Stefferud]

Hi Bob;-)...  And all;-)...

At 12:17 -0700 6/18/03, Bob Braden wrote:
>  *> Keith wrote:
>  *> > If you want to address denial of service issues you need protocol
>  *> > enforcement points.
>  *> 
>  *> NAT is a denial of service attack, not a means of policy enforcement.
>  *> 
>  *> 
>  *> 
>
>Keith,
>
>I think it would be more accurate to say that a NAT contravenes
>the basic Internet prnciple of universal connectivity.
>
>Since 1980 we have believed that universal connectivity was one of the
>great achievements of the Internet design.  Today, one must
>unfortunately question whether universal connectivity can be sustained
>(or is even the right goal) in a networking environment without
>universal trust.  Maybe NATs are, in fact, a result of a very deep
>problem with our architecture.  If you accept that, then there is no
>point in attacking NATs until you can propose a better architectural
>solution to the trust problem (hopefully, there will be one!)
>
>Bob Braden


Here!  Here!  Exactly --  Trust in all the people on the net all the time 
failed with the well received demise of the NSF AUP (1994) and the fact that 
misbehavior then no longer threatened loss of Internet access privileges.

This was not widely recognized as a possible at the time, much like the 
fact that the Internet has no center and hence has no place to locate a 
"Central Control Center" which is another contributor to the loss of trust, 
and which prohibits solving the trust problem with centralized enforcement 
of rules of trust, if any such rules might possibly exist.

This of course is one reason why PKIX is not able to deliver public trust, 
because PKIX requires a single Central Control Center to enforce rules of 
trust (whatever those rules might be), and we have already discussed how it 
is that PKIX CA's suffer from lack of trust induction among their users.

So, one fundamental issue in this whole situation is that the basic "Internet 
Operational Model" that underlays these aspects being discussed here is not a 
realistic model for situations with no available "Center".

I model the Internet more accurately with our present International Economy, 
where again, there is NO CENTER, and thus no place to locate a control center 
for that economy.  The decisions that drive the economy depend on interpersonal 
trust which is developed via multiple channels of information flow derived 
from many different communication paths.  

Trust is only derived from accumulated information obtained from multiple 
channels of information flow.

In the U.S. there is no central control for the National Economy.  And, I have 
been saying for years that pretty much every one that ever had a centrally 
controlled Economy, by now wishes they did not have one.  Even China is 
working its way as carefully as possible to become a free economy, trying 
to avoid the collapse that Russia experienced during such a period of change.

The Internet did it like Russia did it, without understanding that it was 
happening and not dealing with the need for new trust induction tools and 
processes.

So, I think all of you out there will agree that we do not want a return to 
a centrally controlled Internet, even if we could have one, so let's stop 
pretending that such a thing can exist, and start working on ways to induce 
trust among ourselves for all of our own private reasons to have trust among 
us in this "uncontrolled space".

Many hark back to the good old days of the trusted users of he ARPAnet, but 
those days are long gone, when we all had to worry about losing our access 
privileges.  I very well recall my efforts to retain my privileges over those 
years of serving as an independent consultant with no permanent sponsor!

Serving as the "Moderator" of MsgGroup for 11 years from 1975-1986 helped to 
carry me along until 1987 when NSFnet made it easier for me to manage.

>From my management consulting experience along the way, I strongly recommend 
that we learn to live together in our "open information economy" and avoid 
attempts to apply central controls to build mutual trust.  

The Internet is a Internetwork of Internets.  It is not a network!

To repeat, it has no center, and further, does not even have any edges.

It is just a manifold of information transit pipes, each of which can be made 
to communicate with any other transmission pipe, by taking appropriate actions,
without permission from any central governing agency!  Not even ICANNic.

Cheers...\Stef;-)... 

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Valdis . Kletnieks]

On Wed, 18 Jun 2003 21:55:34 PDT, Michel Py said:

> I'm sorry but it is nothing near being that simple. Although if it does
> not work through a firewall, it MAYBE because the firewall does block a
> class of traffic (more likely because someone forgot to punch the right
> hole), there are _plenty_ of other reasons why it does not work through
> a firewall, one of the top ones being asymmetric traffic when there is
> more than one exit point and the firewall hard state not being
> distributed.

OK, so firewalls can fail because they're misconfigured or mis-deployed.

Death of the Internet Predicted.  Film at 11.  This is hardly news. Stuff
doesn't work right if you mis-set your netmask, or your default route, or
your nameserver, or whatever...

The point I was making is that if an NNTP connection fails because the firewall
is *configured* to say 'None Shall Pass' (insert Monty Python .wav here ;)
then that is *proper* behavior.  If a VOIP connection fails because the NAT
is saying 'None Shall Pass', then that's *broken* behavior.

I checked RFC3027.  20 *pages* of things that either break horribly over a NAT,
or (as in the Activision example) say "We can hack this to work if we make
the permanent restriction that there has to be a server that's NOT behind a NAT
and clients have to contact it".  Sounds a lot like RFC3344, actually.

Great.  WHo would *EVER* have thought that the biggest market for IP Mobility
was to hack through NAT dain bramage?


pgp0.pgp
Description: PGP signature

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Eric Rescorla]

[EMAIL PROTECTED] writes:

> On Wed, 18 Jun 2003 21:30:35 PDT, Eric Rescorla said:
> 
> > This seems to me like a false dichotomy. If I were deploying a NAT 
> > (which I didn't) there would be certain things I would care about
> > and others I didn't. If I'm already firewalling off these services,
> > why should I care if NAT blocks them?
> 
> So it's OK for NAT to break any application that *you* don't want to
> let through *your* firewall anyhow.
Yes, it's ok for *my* NAT to do so.

> What's wrong with this picture?  Well.. Sure, if you currently only allow
> 3 ports through your firewall anyhow, and those 3 applications happen to
> be NAT-tolerant, it's probably no impact on YOUR site.
> 
> Of course, if you *ever* encounter an application that your site wants to
> allow through the firewall, but you discover that you STILL can't deploy it
> because NAT breaks it, you'll be wanting some mayonnaise to make that crow
> sandwich go down more easily.
>
> You're missing the point that when a firewall breaks things, it's doing
> its job.  When a NAT breaks things, it's failing to do its job.
Obviously, I disagree.

> Now let's say a firewall is a pair of suspenders, and a NAT is a belt.  This
> makes your position:
> 
> "I don't care that my belt unzips my trousers every time I go through a
> revolving door, because I'm never in a situation where failure of my
> suspenders would be an embarassment".
You've got it absolutely backwards. The fact that the NAT breaks applications
that I don't want to run anyway is a FEATURE, not a bug.

> Tell you what - you round up all the big domains that actually have a clue
> about what they want, and who understand the distinction between a firewall and
> a NAT (even if they are in the same box), and I'll round up all the users who
> are scratching their heads because they have a cablemodem or an ADSL modem
> (either ISP-provided or off the shelf at Walmart) that is an all-in-one modem/
> router/firewall/NAT, and some stuff Just Does Not Work.
> 
> And unfortunately, a lot of the Just Does Not Work stuff are applications
> like H.323 and VOIP that Joe Sixpack actually *might* be interested in.

Ah, the eternal lament of the technocrat who can't understand why the
customers don't want what he knows is so obviously good for them. 

If this were actually a real problem, I'd expect that someone would
be making good money offering service which didn't have this 
problem. Strangely, however, people still seem to buy these products
of which you so obviously disapprove. I guess they don't think the
downside is so terrible.

-Ekr

-- 
[Eric Rescorla   [EMAIL PROTECTED]
   Web Log: http://www.rtfm.com/movabletype

RE: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Michel Py]

> Valdis Kletnieks wrote:
> The point I was making is that if an NNTP connection fails because
> the firewall is *configured* to say 'None Shall Pass' (insert Monty
> Python .wav here ;) then that is *proper* behavior.  If a VOIP
> connection fails because the NAT is saying 'None Shall Pass', then
> that's *broken* behavior.

IMHO what you don't get is that in most cases, BOTH say 'None Shall
Pass' and that would be a normal behavior for both.

Don't get me wrong, I do not defend NAT. The point I was trying to make
is this: it is a waste of time to say that NAT sucks. We know it. For
IPv4, it's too late to change. IMHO, here is the deal: IPv4 NAT does
suck, but there is nothing we can do to remove it; so the only worthy
efforts are 1) maybe try to make it less worse (I will not go as far as
saying better) and 2) let's not make the same mistake with IPv6.

Michel.

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[James Seng]

Why should the users be limited to what IT managers decide is good or bad?

Internet is build on dumb network, smart terminal. End-users are suppose 
to be able to put up their own services, not just running some apps. 
This has been the Internet principles and have serves us well so far.

(The telcos model, OTOH, is the inverse, assuming smart network and very 
very dumb terminal.)

-James Seng

What applications that people want to run--and the IT managers would
want to enable--are actually inhibited by NAT? It seems to me that
most of the applications inconvenienced by NAT are ones that IT
managers would want to screen off anyway.

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Valdis . Kletnieks]

On Wed, 18 Jun 2003 22:19:12 PDT, Eric Rescorla said:

> You've got it absolutely backwards. The fact that the NAT breaks applications
> that I don't want to run anyway is a FEATURE, not a bug.

And the fact that NAT breaks things that you DO want to run is a 

> > And unfortunately, a lot of the Just Does Not Work stuff are applications
> > like H.323 and VOIP that Joe Sixpack actually *might* be interested in.
> 
> Ah, the eternal lament of the technocrat who can't understand why the
> customers don't want what he knows is so obviously good for them. 

No, the lament of a technocrat who can't deploy things that customers DO want
because NAT breaks them.

Find a user.  See if they'd be interested in video or voice over IP.  Watch
them say "ooh... that sounds cool".  Then tell them it would be unreliable
and you could only use it to talk to other users some of the time, because
a lot of users are on these things called NATs, and watch enthusiasm wane.



pgp0.pgp
Description: PGP signature

Re: WG review: Layer 2 Virtual Private Networks (l2vpn)

[Kurt Erik Lindqvist]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

>>> If you use LDP, it is NOT a routing protocol.  The specific mode of 
>>> use
>>> (targeted LDP) is already described in RFC 3036.  The FECs are
>>> different, but
>>> the FEC TLV was defined in such a way as to be extensible.
>>
>> And when you want to do this inter-domain? Everything else seems to
>> have made it's way into BGP so I think that Pekkas concerns are 
>> valid...
>
> That's only because the IETF hasn't made security easy enough, light 
> enough, or
> something.  Now some people use the argument that everything should go 
> into BGP
> because "opening another port into the provider network is a security 
> breach."
> Why is port 646 (LDP) any more insecure than port 179 (BGP)?

Well, I think it's more to it than this. BGP doesn't traverse 
firewalls, at least not in most cases. I think the reason more and more 
is being put into these protocols is because "they are there". It's 
simply easier than thinking about the implications of doing this.
>>>
>>> not
>>> necessarily go down well with you either, but think of MPLS as a
>>> logical FR.
>>> Providers do not want to change their infrastructure, e.g., replace a
>>> FR cloud
>>> with an ATM cloud, then with SONET or GigE.  That's mega-expensive.  
>>> By
>>> abstracting the L2 using MPLS, they can provide the L2VPN service
>>> without
>>> wholesale infrastructure replacement.
>>
>> Most of these providers have bought what their vendor told them to 
>> buy,
>> but let's not go into that here.
>>

Somehow I didn't think this comment would go unnoticed.  ;-)

>
> Sheesh!  No, let's go there.  You're talking about my potential 
> customers, and I
> want to know if they really are so dense that I shouldn't have been 
> spending all
> this time working on a protocol - I could have just given them a 
> couple of
> high-priced tin cans and a piece of string.

Notice that I have been one of those customers. Actually one of the 
largest outside the US. I have spent more time listening and talking to 
vendors on these issues than I like to think about. What struck me was 
how often vendors would come and tell me that provider Y bought this, 
so this should work for you to. When you then asked the vendors to go 
the economics of these decisions, and also the economics of the 
alternatives - you get everything from false and fabricated figures to 
vendors who simply can not answer. I actually remember very few 
occasions  when I got a full explanation of why a certain technology 
would help me and where I could see the benefits.

> Who exactly the IETF is going to be providing protocols for?  For 
> protocols such
> as these, it is the providers who deploy them.  You claim that most of 
> the
> providers have little or no discernment.  Let's give credit to the 
> providers.
> There are a large number of them who know what they are doing.  Many 
> of them
> participate in the standards.

Providers go with technology that is a) cheap b) hight margin. Did 
providers start selling MPLS based VPNs (L2 & L3) because the demand 
was so huge? No, some providers and vendors created the demand. For 
some providers this works very well and fitted the strategy.

Yes, there are providers who work on standards in the IETF. 
Unfortunately I think they are way to few though.

- - kurtis -

-BEGIN PGP SIGNATURE-
Version: PGP 8.0.2

iQA/AwUBPvFLR6arNKXTPFCVEQJ3LgCgzDrvaeUi0j/xWKhBhPNWic9fC2oAoMEj
sTC9ToVkbZP6CRHO/q1uXp64
=rSyl
-END PGP SIGNATURE-

Re: NATs are NOT Firewalls

[Valdis . Kletnieks]

On Thu, 19 Jun 2003 00:55:49 EDT, S Woodside said:
> On Wednesday, June 18, 2003, at 06:28  PM, Tomson Eric ((Yahoo.fr)) 
> wrote:
> 
> > Now, the fact that masking the internal addresses to the external
> > world - so that internal hosts can initiate traffic to the outside, 
> > but no
> > external host can initiate traffic to the inside - brings some basic
> > security, is an interesting corollary, but not the primary objective 
> > of a
> > NAT.
> 
> Is this just security through obscurity, or something better?

Security through obscurity.  See Bellovin's paper on enumerating through a NAT.

Steven M. Bellovin, "A Technique for Counting NATted Hosts. Proc. Second
Internet Measurement Workshop, November 2002.

http://www.research.att.com/~smb/papers/fnat.pdf  (or fnat.ps if you prefer)


pgp0.pgp
Description: PGP signature

Re: myth of the great transition (was US Defense Department formally adopts IPv6)

[James Seng]

If you need a secure zone, and you want a firewall, then should install 
a firewall. You should not put an NAT thinking that it is also a firewall.

But I agree with you that NAT is here to stay.

-James Seng

Fleischman, Eric wrote:
Eric Rescorla [mailto:[EMAIL PROTECTED] wrote:


similarly, people who install NAT usually don't realize how much this
costs them in lost functionality and reliability.


Really? You have evidence of this?


I don't either, but my intuition is that you're wrong.  Once you have
decided to have a firewall in place (which you may think is evil, but
I consider pretty much a necessary evil), I suspect that most people
suffer almost not at all from having a NAT.


I believe that Eric is pointing out an important point: many deployments of NATs have nothing to do with IPv4 address conservation. Rather, they are firewall adjuncts implemented to hide internal networks from outside scrutiny and direct access. 

One point where I disagree with my IPv6-advocating friends is that I expect firewall-related NATs to continue to be deployed within Internet (including IPv6) environments until such a time as real-time-protocol and peer-to-peer-protocol friendly "distributed firewall" (policy zones) variants become the preferable "due diligence" alternative for CIOs.

RE: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[Michel Py]

Valdis,


> Valdis Kletnieks wrote:
> And unfortunately, a lot of the Just Does Not Work stuff are
> applications like H.323 and VOIP that Joe Sixpack actually
> *might* be interested in.

Unfortunately, there is no single reason [protocol or app xyz] does not
work over NAT. When [protocol or app xyz] does not work, it's a
combination of _two_ things.

1. The protocol designer designed a protocol that is not NAT-capable
therefore the protocol designer is stupid.

2. The network administrator tries to run a protocol that is not
NAT-capable over NAT therefore the network administrator is stupid.

As a protocol designer, I will say that the network administrator is the
one being stupid because if s/he even understood the basics of protocol
design s/he would understand why I have to embed the port number in the
packet.

As a network administrator, I will say that the protocol designer is the
one being stupid because if s/he had any clue about what it takes to
operate a network s/he would not have designed a protocol that could not
cross NAT.

Conclusion: this leads us nowhere.

Michel.

Re: myth of the great transition (was US Defense Department forma lly adopts IPv6)

[John Loughney]

Eric,

With due respects, there is a flaw in your thinking. Many ISPs give users NATed 
adresses, without users really knowing or understanding what they are.  When the users 
try applications or serves which fail because of the non-transparency, the users may 
not know the cause of the failures.
I had some VPN software that fails due to NATs in hotels, for example. Support people 
told me that the hotel used NATs for security - I sent a log showing all of the probes 
my macine had from inside the network.
My main point is that users & providers are often confused about NATs.
John 

> What applications that people want to run--and the IT managers would
> want to enable--are actually inhibited by NAT? It seems to me that
> most of the applications inconvenienced by NAT are ones that IT
> managers would want to screen off anyway.