On 13 feb 2008, at 14:44, Jonathan Rosenberg wrote:
> I wrote this because of a discussion that happened during behave at
> the
> last IETF meeting in Vancouver. There was a presentation in the behave
> working group on NAT ALG for SCTP - when run natively over IP - and I
> found the entire conv
Hi Harald,
the problem with a number of the protocols is that they are later used
in a different context.
Take SCTP, for example. Initially, it was meant to be used for
server-to-server communication. Now, some folks obviously want to use it
in a different way.
Whether this is a good idea or n
I am not sure you got Jonathan's idea.
Running protocols on top of UDP does not mean that you don't have
congestion control.
Joel M. Halpern wrote:
> I would disagree about "no drawback."
> The constraints are:
> don't invent new transports
> have congestion control
>
> and, for an important par
Le Thursday 14 February 2008 12:05:37 ext Iljitsch van Beijnum, vous avez
écrit :
> We can have a big, nasty fight about the philosophical points, but
> fortunately, we don't have to, because the whole thing is based on
> incorrect facts. I have never seen a consumer NAT that blocks ICMP.
ICMP is
Harald Tveit Alvestrand wrote:
> While I disagree with Jonathan's assertion that we should insert an
> entirely useless (for all but NAT) UDP header in front of all new
> protocols we design,
Well, I'd hardly characterize, "allowing it to work across the public
Internet" as a property that is
> Well, I'd hardly characterize, "allowing it to work across the public
> Internet" as a property that is useless. Statements like, "useless for
> all but NAT" trivialize what the Internet has evolved into. There is NAT
> everywhere. Lets accept it and design for what the Internet is, and not
> for
On 14 feb 2008, at 12:03, Rémi Denis-Courmont wrote:
>> We can have a big, nasty fight about the philosophical points, but
>> fortunately, we don't have to, because the whole thing is based on
>> incorrect facts. I have never seen a consumer NAT that blocks ICMP.
> ICMP is not a transport protoco
On 14 feb 2008, at 15:51, Christian Huitema wrote:
> We don't see NAT on IPv6. However, we do see "statefull firewalls",
> and they have the same practical effect. They block any conversation
> if it was not originated "from inside the network", and for that
> they look at TCP and UDP port n
>> So as was already mentioned, one could
>> argue the waist hourglass is HTTP and HTTP/SSL, and this discussion is
>> irrelevant.
>>
>
> Many NATs and firewalls block incoming TCP sessions or unexpected UDP
> packets. So if we use the logic "only stuff that works on 100% of all
> hosts c
On 2/14/08 9:58 AM, "Iljitsch van Beijnum" <[EMAIL PROTECTED]> wrote:
> Disagree. There is no reason why a stateful firewall would have an
> easier time tracking UDP state than any other non-TCP state when there
> is no address translation.
There's just a lot more experience with UDP than there
is
Le Thursday 14 February 2008 16:51:21 ext Iljitsch van Beijnum, vous avez
écrit :
> > also 6to4 does not work through many NATs.
>
> The reason that as a rule, you can't do 6to4 through NAT is because
> you don't know your 6to4 prefix if you don't know your real IPv4
> address. Whether the packets
> Disagree. There is no reason why a stateful firewall would have an
> easier time tracking UDP state than any other non-TCP state when there
> is no address translation.
I believe the point here is that a stateful firewall installs a binding
based on an initial packet from INSIDE the firewall, a
Hi Melinda,
> You definitely do
> not want to design a mechanism that enables policy
> violation.
>
>
I have just been waiting for this comment.
Interestingly, you could combine mechanisms, namely
* mechanisms that traverse the NAT/firewall and do not require cooperation
* mechanisms that
Our site is still down for the move at the moment, should be back up
soon. That site lists all of the nearby hotels, most of which have a
special Comcast rate. I would simply ask that you read the "special
rate notice" at the bottom of our hotels page and let me know if I can
assist further.
Jas
> On 13 feb 2008, at 14:44, Jonathan Rosenberg wrote:
> > I wrote this because of a discussion that happened during behave at the
> > last IETF meeting in Vancouver. There was a presentation in the behave
> > working group on NAT ALG for SCTP - when run natively over IP - and I
> > found the entir
> Mind you, I'm not saying that protocols should always use a UDP
> shim layer. But I think the tradeoffs in favor of doing so are a bit
> stronger
> than you seem to think.
This is my chance to act the naif for Valentine's Day, but ...
I agree that UDP shims improve your ability to get through
What I took from Jonathan's draft was the sense (correct in my view)
that if we want new protocols to be successfully *deployed* in actual
production networks and communicate across the firewall (which may or
may not be doing NAT) to the public Internet, they should ideally sit
on top of ei
Spencer Dawkins wrote:
>> Mind you, I'm not saying that protocols should always use a UDP
>> shim layer. But I think the tradeoffs in favor of doing so are a bit
>> stronger
>> than you seem to think.
>
> This is my chance to act the naif for Valentine's Day, but ...
>
> I agree that UDP shims
inline:
Michael Thomas wrote:
> Jonathan Rosenberg wrote:
>> Harald Tveit Alvestrand wrote:
>>
>>> While I disagree with Jonathan's assertion that we should insert an
>>> entirely useless (for all but NAT) UDP header in front of all new
>>> protocols we design,
>>>
>>
>> Well, I'd hardly
Jonathan Rosenberg wrote:
>
>> More heresy: maybe we should work on hacks to TCP to allow it to
>> have non-reliable e2e delivery so that it was more friendly to real time
>> protocols built on top of it.
>
> As you probably know folks absolutely have done this for exactly the
> reason you cite.
First, I do agree that for operation through NATs, and even Firewalls,
having the UDP header has been demonstrated to significantly simplify
things, and is probably sensible. (My earlier notes were prompted by a
tone that said ~therefore all work we do should be over UDP or TCP.
Always.~)
Let
Jonathan Rosenberg wrote:
> Harald Tveit Alvestrand wrote:
>
>> While I disagree with Jonathan's assertion that we should insert an
>> entirely useless (for all but NAT) UDP header in front of all new
>> protocols we design,
>>
>
> Well, I'd hardly characterize, "allowing it to work acros
As with most protocol design issues, this is a problem that becomes much
easier to deal with if there is a frank and realistic understanding of
the real world constraints.
While UDP or TCP are acceptable for virtually all protocol needs there
are many protocols for which they are not optimal.
Completely unrelated, what is the subject tag [dkim unverified]
supposed to do ? Is that some joke in the spirit of RFC 4096 ?
As far as I can see it your mail from cisco.com got an SPF PASS
at core3.amsl.com, an unidentified agent claims to have seen a
DKIM PASS for [EMAIL PROTECTED], and finall
On 14 feb 2008, at 21:21, Dan Wing wrote:
> What seems useful is a mechanism where the UDP encapsulation can be
> attempted and the native (non-UDP encapsulted) protocol can be
> attempted.
I was thinking along similar lines. Notwithstanding what I said
earlier, sometimes encapsulating somethin
Joel M. Halpern wrote:
...
> I think that the key question that Jonathan's draft drives us
> towards is whether work like the SCTP / UDP draft Dan Wing pointed
> out needs to get more attention. And soon. It does seem to me that
> being able to run the applications which drove SCTP and DCCP over
Dear all,
just a comment inline.
Best regards
Michael
On Feb 14, 2008, at 4:09 PM, Rémi Denis-Courmont wrote:
> Le Thursday 14 February 2008 16:51:21 ext Iljitsch van Beijnum, vous
> avez
> écrit :
>>> also 6to4 does not work through many NATs.
>>
>> The reason that as a rule, you can't do 6to
The actual encoding of the packets into UDP is the simple part.
The difficult part is to get the rest to work since you have to combine
it with a protocol that offers the end-to-end connectivity and to get
the rest to work.
Iljitsch van Beijnum wrote:
> On 14 feb 2008, at 21:21, Dan Wing wrote
* michael dillon:
> Is TCP/UDP the right place which we should try to reinforce, or
> should we instead try to move it back down to IP as version 6
> becomes more widely deployed?
The prevailing assumption is that IPv6 end nodes will be globally
addressable for practical purporses. I think this
Iljitsch van Beijnum wrote:
> On 14 feb 2008, at 21:21, Dan Wing wrote:
>
>> What seems useful is a mechanism where the UDP encapsulation can be
>> attempted and the native (non-UDP encapsulted) protocol can be
>> attempted.
>
> I was thinking along similar lines. Notwithstanding what I said
On 14 feb 2008, at 22:24, Jonathan Rosenberg wrote:
>> But it seems to me that a much better approach to this is first of
>> all to make it optional, like you suggest, and secondly, make it a
>> generic mechanism that can be used for ALL protocols rather that
>> define it separately for o
Ralph
Have you been following this thread? What odd questions and
assumptions...appears as if folk have no idea re: IPv6 addressing ..all end
nodes will be globally addressable for 'practical purposes' is such an odd
statement to make...either:
1. meaning that all end nodes will have globally uni
Hi Ted,
I agree with you on the notion that we shouldn't publish anything that we
know already that will need fixes or does not work properly for the intended
use at this point. However, I think it is completely proper to revise
specifications based on operational experience - ever rather quickly
On 14 feb 2008, at 21:49, Florian Weimer wrote:
> The prevailing assumption is that IPv6 end nodes will be globally
> addressable for practical purporses. I think this is a very unlikely
> outcome.
Are you saying that there will be IPv6 NAT?
And that we should design protocols running on top of
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-carpenter-r
On Feb 14, 2008, at 4:16 PM, Iljitsch van Beijnum wrote:
On 14 feb 2008, at 21:49, Florian Weimer wrote:
The prevailing assumption is that IPv6 end nodes will be globally
addressable for practical purporses. I think this is a very unlikely
outcome.
Are you saying that there will be IPv6 NA
Spencer Dawkins wrote:
> Does this document actually obsolete "STD1"? I'm not even sure what
> that means... :-(
Good question. Guessing, it means that the status of STD 68 claims
that there is an STD 1, while STD 1 claims that there is no STD 66,
let alone any STD 68. Go figure... :-|
> If 2
Dan York wrote:
>> Are you saying that there will be IPv6 NAT?
> Absolutely. 100% guaranteed that some organizations out there will
> continue to use NAT even with IPv6.
Just as NTT is already using closed IPv6 network for their NGN-like
service, mobile telephone operators will use closed IP
I can try pulling something together based on some of the numbers from
the messages that followed... When would you need them?
On Wed, 2008-02-13 at 14:05 -0500, Henning Schulzrinne wrote:
> I'm looking for a reasonably recent presentation on the state of IP
> address allocation that would be su
Hi Jonne,
Thanks for your reply; some comments inline.
At 1:17 PM -0800 2/14/08, Soininen Jonne (NSN FI/Espoo) wrote:
>Hi Ted,
>
>I agree with you on the notion that we shouldn't publish anything that we
>know already that will need fixes or does not work properly for the intended
>use at
--On 14. februar 2008 08:38 -0800 "Hallam-Baker, Phillip"
<[EMAIL PROTECTED]> wrote:
>
> As with most protocol design issues, this is a problem that becomes much
> easier to deal with if there is a frank and realistic understanding of
> the real world constraints.
>
> While UDP or TCP are accep
Hi Ted,
Thanks for the review. Please see inline.
Regards
Sri
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Ted Hardie
> Sent: Wednesday, February 13, 2008 5:01 PM
> To: [EMAIL PROTECTED]; ietf@ietf.org
> Subject: Re: Last Call on draft-ietf-
Spencer Dawkins wrote:
> Hi, Hannes,
>
> I can't answer for Jonathan, but I wondered the same thing, and decided that
> the answer was probably one of
>
> - "well, if we all know this, what are we doing differently now that we know
> it?", or
How not to have this happen in ipv6?
> - "
On Wed, 13 Feb 2008, Henning Schulzrinne wrote:
> I'm looking for a reasonably recent presentation on the state of IP
> address allocation that would be suitable for a class I'm teaching.
Henning -
Duane Wessels of The Measurement Factory has created some
great maps of current v4 allocations:
h
Total of 150 messages in the last 7 days.
script run at: Fri Feb 15 00:53:01 EST 2008
Messages | Bytes| Who
+--++--+
8.00% | 12 | 5.71% |64180 | [EMAIL PROTECTED]
3.33% |5 | 6.77% |76081 | [EMAIL PROTECTE
45 matches
Mail list logo
