> > no, that would be *really* ugly. because then you'd expect the
> > NAT box to know how to intercept every application you'd want
> > to use, despite the fact that those applications are evolving
> > and the set of those apps is changing constantly. so you'd have
> > to upgrade your NAT every t
> >use of SRV records for apps that aren't specified to use them is a
> >violation of both those apps' protocols and the SRV specification.
> >
> >
> Agreed. But it's an option for people who need to build new apps to
> kludge around NATs.
presuming, of course, that the app only needs to commu
> what you propose would make every app NAT-sensitive, and
> increase the rate of failures due to intermediaries that
> intercept protocol interactions and botch them.
You do have a point here. Stupid idea it was.
Michel.
] Michel Py wrote:
] But what would be _really_ cool is if you could do this:
] Server1: 192.168.1.10:80 <-> x.y.z.t:80
] Server2: 192.168.1.11:80 <-> x.y.z.t:80
] Server3: 192.168.1.12:80 <-> x.y.z.t:80
] ** and ** have the UPNP box select the proper NAT association
] based on the requests.
> Kei
On Wed, 25 Jun 2003, Yakov Rekhter wrote:
> > > 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 cha
On Thu, 19 Jun 2003, grenville armitage wrote:
> Pekka Savola wrote:
> [..]
> > Moreover, we work on an IP layer. We enable IP layer to be able to handle
> > our tasks. If there is some problem why we cannot just use different IP
> > subnets between the two (or multiple) end-points, we need
Randy,
> > "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 don
Pekka,
[clipped...]
> > 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 pr
] >That's were the coolness is; no stinkin' port number.
] >
] >
] You could publish URLs without port numbers if you could count on the
] cliens recognizing SRV records.
but you can't, because this would break interoperability with the vast
majority of existing protocols; it also would not wor
Keith Moore wrote:
] You could publish URLs without port numbers if you could count on the
] cliens recognizing SRV records.
use of SRV records for apps that aren't specified to use them is a
violation of both those apps' protocols and the SRV specification.
Agreed. But it's an option for pe
] But what would be _really_ cool is if you could do this:
]
] Server1: 192.168.1.10:80 <-> x.y.z.t:80
] Server2: 192.168.1.11:80 <-> x.y.z.t:80
] Server3: 192.168.1.12:80 <-> x.y.z.t:80
] ** and ** have the UPNP box select the proper NAT association based on
] the requests.
no, that would be *re
Melinda,
> > 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.
What makes y
> From: Yakov Rekhter <[EMAIL PROTECTED]>
> ...
> In the rather arrogant terms of internet engineering, the IESG is by
> definition the set of people that are "clueless". It is not possible
> for it to be the other way around. No matter how wise and inteligent
> IESG memebers are...
>
> It is nece
Michel Py wrote:
In DNS you publish:
x.y.z.t server1.example.com
x.y.z.t server2.example.com
x.y.z.t server3.example.com
[...]
That's were the coolness is; no stinkin' port number.
You could publish URLs without port numbers if you could count on the
clients recognizing SRV records.
--
/=
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 g
Christian,
> Christian Huitema wrote:
> I don't quite get the point on the handling of
> incoming connections
The way I understand UPNP is that it will allow the automation (meaning,
no manual config of the NAPT box) of:
Server1: 192.168.1.10:80 <-> x.y.z.t:81
Server2: 192.168.1.11:80 <-> x.y.z
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 g
Paul,
> >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
18 matches
Mail list logo
