Mark Andrews wrote:
>
> And if you stop thinking IPv6 == IPv4 + big addresses and
> start thinking multiple IPv6 addresses including a ULA IPv6
> address + RFC 3484 you get local address stability without
> needing a NAT. You use ULAs for internal communication and
>
Joel M. Halpern wrote:
> As far as I can tell, most of what is being asked for here has little,
> if anything, to do with NAT. To paraphrase:
>
> If we are going to have firewalls which block incoming connections,
> communication between entities behind such firewalls should still be
> possible w
As far as I can tell, most of what is being asked for here has little,
if anything, to do with NAT. To paraphrase:
If we are going to have firewalls which block incoming connections,
communication between entities behind such firewalls should still be
possible without any "external" servers.
FWIW - I wholeheartedly agree with
"If we're going to standardize NATs of any kind, they need to be defined in
such a way that no "external" server is necessary - not to determine one's
external IP address, nor to forward traffic between hosts that are all
behind NATs, nor to maintain state in the
Ben Campbell wrote:
--Don't forget the new boilerplate, depending on the timing of
publication
I submitted a draft earlier today and (reluctantly) had to settle for
the old boilerplate, because:
(a) xml2rfc doesn't yet support the new boilerplate, and
(b) the official "Legal Provisions" d
At 6:07 PM -0800 11/25/08, David Conrad wrote:
>Tony,
>
>On Nov 25, 2008, at 4:41 PM, Tony Hain wrote:
>> Either way the
>> app developers will have to rely on topology awareness crutches to
>> deal with
>> the resulting nonsense.
>
>Stuff they presumably already have to deal with because they'd l
In message <[EMAIL PROTECTED]>, David Mo
rris writes:
> On Thu, 27 Nov 2008, Mark Andrews wrote:
> >
> > If your OS requires a reboot when you renumber get a real OS.
> > If your apps require that they restart when you renumber get
> > your apps fixed.
>
> I fail to understand how an
David Morris wrote:
> On Thu, 27 Nov 2008, Mark Andrews wrote:
>
> >
> > If your OS requires a reboot when you renumber get a real OS.
> > If your apps require that they restart when you renumber get
> > your apps fixed.
>
> I fail to understand how an app such as ssh can maintain a s
On Nov 26, 2008, at 10:05 AM, John C Klensin wrote:
I also assume those clients will be performing validation
against a signed root zone,
Sure, if they configure their trust anchor according to
https://ns.iana.org/dnssec/status.html
(There are other testbeds too, but I don't recall where to d
In message <[EMAIL PROTECTED]>, Russ Housley writes:
> I have been approached about a plenary experiment regarding
> DNSSEC. The idea is for everyone to try using DNSSEC-enabled clients
> during the plenary session. I like the idea. What do others think?
>
> Russ
>
> ___
On Thu, 27 Nov 2008, Mark Andrews wrote:
>
> If your OS requires a reboot when you renumber get a real OS.
> If your apps require that they restart when you renumber get
> your apps fixed.
I fail to understand how an app such as ssh can maintain a secure
connection in the face
In message <[EMAIL PROTECTED]
om>, "Hallam-Baker, Phillip" writes:
> This is a multi-part message in MIME format.
>
> Eric,
>
> The problem here is that you assume that the IETF has decision power
> that can magic away NAT66. Clearly it did not for NAT44 and will not for
> NAT66.
>
> So the real
+1
John C Klensin wrote:
>
> --On Wednesday, 26 November, 2008 10:50 -0500 Russ Housley
> <[EMAIL PROTECTED]> wrote:
>
>> I have been approached about a plenary experiment regarding
>> DNSSEC. The idea is for everyone to try using DNSSEC-enabled
>> clients during the plenary session. I like th
Hallam-Baker, Phillip wrote:
> Could we agree on a consensus point that:
>
> 'Any application developer who designs a protocol on the assumption it
> will not be subject to NAT66 may be disappointed'
I think it would be far more constructive to tell application developers
what they _can_ assume.
Sam,
I agree with Russ. I think the clearest possible result is the one
we achieved in the case appended below, but that required quite
some work in the absence of a well-defined procedure, even without
there being an independent submission to synchronize. I think the
draft makes such cases easier
On Wed, Nov 26, 2008 at 10:50:56AM -0500, Russ Housley wrote:
> I have been approached about a plenary experiment regarding
> DNSSEC. The idea is for everyone to try using DNSSEC-enabled clients
> during the plenary session. I like the idea. What do others think?
>
> Russ
>
nifty! jck shar
On Nov 26, 2008, at 12:17 PM, [EMAIL PROTECTED] wrote:
In any case, I think getting renumbering right and getting it
deployed is an
essential step in minimizing the use of NAT66.
This seems to ignore the fact that we already have a widely deployed
solution to site renumbering: NAT.
IPv4
Hi -
> From: "james woodyatt" <[EMAIL PROTECTED]>
> To: "Behave WG" <[EMAIL PROTECTED]>
> Cc:
> Sent: Tuesday, November 25, 2008 4:34 PM
> Subject: Re: [BEHAVE] Lack of need for 66nat : Long term impact to
> applicationdevelopers
...
> The basic problem with NAT66 is that it introduces the possi
Hi Ben,
Oops, I messed up the Gen-ART review boilerplate. Please mentally insert
the following text at the top of my review:
I think we'll let you off just this once.
Document: draft-ietf-mpls-te-scaling-analysis-03
Reviewer: Ben Campbell
Review Date: 2008-11-25
IETF LC End Date: 2008-11-3
--On Wednesday, 26 November, 2008 10:50 -0500 Russ Housley
<[EMAIL PROTECTED]> wrote:
> I have been approached about a plenary experiment regarding
> DNSSEC. The idea is for everyone to try using DNSSEC-enabled
> clients during the plenary session. I like the idea. What do
> others think?
I
Ned raises one firewall concern: they block applications that should work.
I have another concern: many are completely insecure as configured. It is not
completely unusual to find a $200,000 firewall configuration that could be
replaced with an ethernet patch cable. I have seen it: some consult
Sam:
That said, I'm puzzled by the continued inclusion of "rejected
alternative bypass" as a reason to delay publication. In section 4,
this document proposes that readers could be confused by the order of
publication of documents. At the same time, this document is removing
the mandatory IESG
I have been approached about a plenary experiment regarding
DNSSEC. The idea is for everyone to try using DNSSEC-enabled clients
during the plenary session. I like the idea. What do others think?
Russ
___
Ietf mailing list
Ietf@ietf.org
https://ww
> The problem here is that you assume that the IETF has decision power that can
> magic away NAT66. Clearly it did not for NAT44 and will not for NAT66.
I really hope you aren't correct about this, but I fear you are.
> So the real question for App designers is:
> 1) Should they design protoco
I don't quite understand what you men by this.
My internal DNS for the house does not reveal the existence of any of the
machines to the outside world. Multiple horizons have been a feature of DNS for
decades now.
The only thing global about DNS is that there is only one consensus holder of a
While most of the discussion about killing NAT66 is happening on the
IETF list, we have a much more constructive discussion going on in
behave regarding how to define an IPv6 NAT that will meet the needs of
network administrators and end-users, while being less destructive to
the Internet
Keith More writes:
>I don't think so in either case. The reason I don't think so is that I
>suspect the NAT traversal problem is really a firewall traversal problem
>in disguise.
Absolutely, and that is why there needs to be a permissions system that allows
effective decisions to be made wit
Eric,
The problem here is that you assume that the IETF has decision power that can
magic away NAT66. Clearly it did not for NAT44 and will not for NAT66.
So the real question for App designers is:
1) Should they design protocols that assume no NAT66
2) Should they regard the assumption tha
The problem here is that the Behave group seems to have people who are making
IETF wide policy. So that is why opponents of the behave position think that
the appropriate forum is the IETF list.
Behave can decide not to do a NAT66.
But what they cannot do is to decide that NAT66 should be pro
Could we agree on a consensus point that:
'Any application developer who designs a protocol on the assumption it will not
be subject to NAT66 may be disappointed'
I think that it is beyond rational argument to claim otherwise. Furthermore, if
it is really the interests of application layer pr
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
On Nov 25, 2008, at 15:11, Sam Hartman wrote:
Keith, would the NAT-66 proposal plus some mechanism for a server
inside the NAT to ask the NAT for its global address be sufficient to
meet the needs described above?
No. RFC 3424 is the IAB Considerations document covering that
problem. I'm t
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like
[Behave dropped, this is an architectural level discussion. If we don't want
this on ietf we should start a different forum]
I don't think that this claim is right: "Promoters of NAT, particularly
vendors, seem to have a two-valued
view of the network in which inside is good and outside is evil
Please,
any input into this debate shall go to the behave list. People
interested in this topic please subscribe to Behave.
Regards
Magnus
Peter Dambier skrev:
> Keith Moore wrote:
>
>> absolutely it's too onerous. why in the world should an application's
>> deployability depend on the existe
Oops, I messed up the Gen-ART review boilerplate. Please mentally
insert the following text at the top of my review:
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.ht
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-igoe-secs
> From: David Conrad <[EMAIL PROTECTED]>
> The architecture is _ALREADY_ broken. 66NAT is merely another symptom
> of the underlying disease.
Hey, that's what happens when you pick as 'the next generation of networking',
"X.25 with a larger sequence number space" (or, for you youngste
> Yeah, but we're trying to get rid of that stuff, or at least
> considerably reduce the cost and complexity, because (among other
> things) it presents a huge barrier to adoption of new multiparty apps.
Promoters of NAT, particularly vendors, seem to have a two-valued
view of the network in whic
On 25 nov 2008, at 23:10, Tony Hain wrote:
Iljitsch van Beijnum wrote:
...
But in any event, compared to the backflips through flaming hoops we
have to do in IPv4, the asking a remote server what our source
address
looks like from the outside to make address based referrals work
doesn't seem
40 matches
Mail list logo
