On 2 dec 2008, at 5:37, Keith Moore wrote:
I don't think it's just that the multi-prefix model is unfamiliar.
There's plenty of reason to believe that it won't work well. Static
address selection rules, no way for hosts to know which prefixes will
work better, inability of most existing
One of the topics that came up in the architectural debate is that a few folk
made statements of the form that application developers assume that
applications only engage in bilateral communications. In fact one person went
so far that applications developers are not aware of the range of
Christian Huitema wrote:
I'm not sure I believe in the need for topology hiding. But if I
did,
on v6 I'd just allocate a separate subnet or group of subnets for
external access. If really necessary, have such hosts set up IP over
IP or L2TP tunnels to a concentrator; that will make this
Tony Hain skrev:
Cullen Jennings wrote:
I'm sure that the IAB and IESG is keenly interested in this topic but
everyone that cares is subscribed to behave.
While I agree that everyone interested in defining nat behavior is
subscribed to Behave, I doubt that everyone in the application
--On Tuesday, 02 December, 2008 07:04 -0800 Hallam-Baker,
Phillip [EMAIL PROTECTED] wrote:
One of the topics that came up in the architectural debate is
that a few folk made statements of the form that application
developers assume that applications only engage in bilateral
communications.
It was not clear from the context of the argument what was being referred to.
Seemed more likely that they were imaging something involving more parties than
bilateral. It was one of those 'well people only disagree with me because they
are ignorant of an area that I will specify so vaguely a
--On Wednesday, November 26, 2008 02:58:25 AM -0500 Samuel Weiler
[EMAIL PROTECTED] wrote:
The security considerations section cites rogue DHCP servers as attack
vectors, but doesn't do enough to encourage the use of DHCP Auth.
In many deployments, DHCP is used by devices which have no prior
Actually, rather than tunneling, have we seriously consider flat host
based routing in a corporate network? A combination of DHT and
caching technologies ought to make that quite scalable.
I've used large, flat networks, and lived to regret it
Do we have a documentation somewhere
I would suggest that there is at least one other block of people who
are missing from the list of stakeholders in the To NAT or not to NAT
in IPv6 discussion that Keith Moore listed:
On Dec 1, 2008, at 3:52 PM, Keith Moore wrote:
- The greatest concentration of NAT experts in the IETF are
Hi All,
Can anyone tell me what will the EMM state(either EMM Deregistered/idle)
after receiving RESET message from MME at the eNB.
Regards
Bivu
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
you might take a look at he nat66 document and the behave IPv4/IPv6
documents. they're pretty different.
On Dec 1, 2008, at 7:07 PM, Christian Huitema wrote:
Of course, Iljitsch points an interesting issue. If NAT66 behaves
exactly like, say, NAT 64, then why would the organization bother
On Dec 1, 2008, at 10:41 PM, Christian Huitema wrote:
Actually, rather than tunneling, have we seriously consider flat
host based routing in a corporate network? A combination of DHT and
caching technologies ought to make that quite scalable.
We built a number of networks like those in
From: Dan York [EMAIL PROTECTED]
it's simple and easy and **that's what they know**
Not to mention that nobody ever got fired for deploying NAT...
Noel
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
At 2:57 AM -0800 12/2/08, Iljitsch van Beijnum wrote:
On 2 dec 2008, at 5:37, Keith Moore wrote:
I don't think it's just that the multi-prefix model is unfamiliar.
There's plenty of reason to believe that it won't work well. Static
address selection rules, no way for hosts to know which
On 2 dec 2008, at 18:46, Ted Hardie wrote:
One way to fix that would be multipath transport protocols. Rather
than try to guess what works best, just use all of them (or at least
several) and get better performance without having to make difficult
choices.
It's not clear to me from the above
Excerpts from Brian E Carpenter on Tue, Dec 02, 2008 12:02:25PM +1300:
1. We know of no alternative to a longest-match based approach to
routing lookup for the inter-AS routing system (commonly known as
the DFZ).
2. To control the long-term scaling of that approach, we need to
control the
Excerpts from Iljitsch van Beijnum on Tue, Dec 02, 2008 11:57:07AM +0100:
On 2 dec 2008, at 5:37, Keith Moore wrote:
I don't think it's just that the multi-prefix model is unfamiliar.
There's plenty of reason to believe that it won't work well. Static
address selection rules, no way for hosts
On 2 dec 2008, at 20:02, Scott Brim wrote:
One way to fix that would be multipath transport protocols. Rather
than
try to guess what works best, just use all of them (or at least
several)
and get better performance without having to make difficult choices.
This doesn't help with site
Iljitsch - I understand the theory behind what you're describing...in
practice, it's a hard problem to know where all the prefixes are that
should be changed; worse yet, it's hard to know which prefixes in
which parts of the configuration should be replaced with new prefixes,
and which
Why should anyone care if an internal network is on IPv6 or not? That is
probably the silliest part of the NAT66 debate. I am only going to be deploying
IPv6 for the few hosts that actually need to receive inbound connections. And I
don't expect that to be more than a few hosts on a home
Thanks for your review, Colin.
I agree that fixes or better explanations of the background should be
given for the points that you raised. It seems that you and Hesham are
making progress on what needs to be added to the document, great!
The only item that I too am somewhat worried about in
Sam - I think most of the issues in your review of draft-raj-dhc-tftp-
addr-option-04 can be resolved by reviewing the purposes of RFC 3942
and publishing Informational RFCs describing DHCP option codes.
Fundamentally, the reason to publish RFCs under the process described
in RFC 3942 is
--On Tuesday, 02 December, 2008 15:23 -0500 Ralph Droms
[EMAIL PROTECTED] wrote:
Sam - I think most of the issues in your review of
draft-raj-dhc-tftp-addr-option-04 can be resolved by reviewing
the purposes of RFC 3942 and publishing Informational RFCs
describing DHCP option codes.
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:
--On Tuesday, 02 December, 2008 08:52 -0800 Hallam-Baker,
Phillip [EMAIL PROTECTED] wrote:
It was not clear from the context of the argument what was
being referred to. Seemed more likely that they were imaging
something involving more parties than bilateral. It was one of
those 'well
--On Tuesday, December 02, 2008 03:53:58 PM -0500 John C Klensin
[EMAIL PROTECTED] wrote:
--On Tuesday, 02 December, 2008 15:23 -0500 Ralph Droms
[EMAIL PROTECTED] wrote:
Sam - I think most of the issues in your review of
draft-raj-dhc-tftp-addr-option-04 can be resolved by reviewing
the
(replying to ietf@)
On Wed, Nov 26, 2008 at 09:38:02AM -0800, Bernard Aboba wrote:
One such issue is how to rapidly seed the learning tables
and ARP caches on movement between attachment points.
ARP cache updates shouldn't be necessary when changing attachment
points unless the client's MAC
Samuel Weiler skrev:
On Wed, 26 Nov 2008, Russ Housley wrote:
2. Independent submission informational RFC
...
Today, the IESG asks the RFC Editor to hold the rejected alternative
until the standards-track document is in the RFC Editor queue, and
the informational document will be published
The IESG has approved the following document:
- 'Diameter ITU-T Rw Policy Enforcement Interface Application '
draft-sun-dime-itu-t-rw-02.txt as an Informational RFC
This document has been reviewed in the IETF but is not the product of an
IETF Working Group.
The IESG contact person is Dan
29 matches
Mail list logo
