but when similar things were proposed
at other meetings, somebody always said no! we have to have end-
to-end,
and if we'd wanted nat-around-every-net we'd've stuck with IPv4.
Is VJ compression considered a violation of the end-to-end
principle?
Or perhaps I misunderstand (yet again).
Hi Tony,
On Sat, 15 Oct 2005 23:26:20 -0700
Tony Li [EMAIL PROTECTED] wrote:
snip
Perhaps
this is yet another case where people misunderstand the principle
itself and are invoking it to give a name to their (well placed)
architectural distaste.
Doesn't NAT, or more specifically
Tony,
On Oct 15, 2005, at 11:26 PM, Tony Li wrote:
Paul is correct. Things that looked like NAT were rejected because
NAT is evil.
Religion is so much fun.
Shifting the NAT to end system removed the objection to NAT, tho
it's not entirely clear why. Shifting NAT to the end system also
On Sun, 16 Oct 2005, Christopher L. Morrow wrote:
I don't want to speak for Daniel, nor other operators really, but a
solution that doesn't allow an operator to traffic engineer
internally or externally is just not workable. For the same reasons
quoted in your other messages to me: Increased
Hi David,
snip
Well, if you NAT the destination identifier into a routing locator
when a packet traverses the source edge/core boundary and NAT the
locator back into the original destination identifier when you get to
the core/destination edge boundary, it might be relevant. The
Shifting the NAT to end system removed the objection to NAT, tho
it's not entirely clear why. Shifting NAT to the end system also
happened to simplify the entire solution as well.
Except for the part about having to rewrite all existing
implementations to take full advantage of the
Certainly does. Apparently this or a similar idea was suggested
back in
1997, and is the root origin of the 64 bits for host address space,
according to Christian Huitema, in his IPv6 book -
http://www.huitema.net/ipv6.asp.
A google search found the draft :
GSE - An Alternate Addressing
Tony Li wrote:
It's just a mess. I think that we all can agree that a real locator/
identifier split is the correct architectural direction, but that's
simply not politically tractable. If the real message that the
provider community is trying to send is that they want this, and not
Doesn't NAT, or more specifically the most commonly used, NAPT, create
hard state within the network, which then makes it violate the
end-to-end argument ? Also, because it has to understand transport and
application layer protocols, to be able to translate embedded
addresses,
doesn't this
How is a split between locator / identifier any different logicaly
from the existing ipv4 source routing?
IPv4 source routing, as it exists today, is an extremely limited
mechanism for specifying waypoints along the path to the destination.
This is completely orthogonal to a real
On Sun, 16 Oct 2005, Joe Maimon wrote:
Tony Li wrote:
It's just a mess. I think that we all can agree that a real locator/
identifier split is the correct architectural direction, but that's
simply not politically tractable. If the real message that the
provider community is
Tony Li wrote:
How is a split between locator / identifier any different logicaly
from the existing ipv4 source routing?
IPv4 source routing, as it exists today, is an extremely limited
mechanism for specifying waypoints along the path to the destination.
IOW the end stations were
Mike Leber wrote:
On Sun, 16 Oct 2005, Joe Maimon wrote:
For example, if your goal was to have TCP-like sessions between
identifiers survive network events without globally propagating full
network topology information about your site (the gripe against classic
IPv4 BGP) you could have
On Sun, 16 Oct 2005, Joe Maimon wrote:
Mike Leber wrote:
On Sun, 16 Oct 2005, Joe Maimon wrote:
For example, if your goal was to have TCP-like sessions between
identifiers survive network events without globally propagating full
network topology information about your site (the gripe
On Sun, 16 Oct 2005, Mike Leber wrote:
Does shim6 require new protocol stacks on the hosts at both ends of a
session? (If not then the source is not making its own path selection
decisions.)
As I understood it, shim6 is a way for two hosts to communicate between
each other that they have
Think in the future, do we really want routers that'll handle millions of
prefixes and hundreds of thousands of AS numbers, just because people want
resiliance?
Something will have to provide it and I don't want it to be each of my
hosts. I'd rather the hundreds of hosts handle payload and
The problem with that (and many premises) is that we need to remember these
arguments and foreseen problems were all dreamed up 10 or so years ago.
The status of everyone's network, everyone's business needs and everyone's
network design (and capabilities) were drastically different that long
Kevin Loch writes:
Does anyone have reachability data for c-root during this episode?
The RIPE NCC DNSMON service has some:
http://dnsmon.ripe.net/dns-servmon/server/plot?server=c.root-servers.nettype=dropststart=1128246543tstop=1128972253
According to BGPlay for that particular prefix from
Forgot to subscribe to nanog-post first time round...
Forwarded Message
On Sun, 2005-10-16 at 05:31 -0400, Joe Maimon wrote:
Long story short, seperating endpoint/locator does nothing to allow
multiple paths to a single IP6 address/prefix to scale.
I may be wrong - I
# but when similar things were proposed at other meetings, somebody always
# said no! we have to have end-to- end, and if we'd wanted
# nat-around-every-net we'd've stuck with IPv4.
#
# Is VJ compression considered a violation of the end-to-end principle?
#
# Or perhaps I misunderstand (yet
there is no hope in having operators explain to ietf that the current path
is fruitless? certainly they can be made to see the light, yes?
you have not spent much time with the ivtf, have you?
Actually Chris has been extremely active in the IETF - his draft on
current/desired router
Daniel Roesen writes:
On Fri, Oct 14, 2005 at 10:45:33PM -0400, Todd Vierling wrote:
Maybe to start -- but again, what kind of 6to4 traffic level are we
expecting yet?
Peak or average? Think twice before answering. :-)
I'm told there are 6to4 relays seeing in excess of 100mbps. Not
On 16-Oct-2005, at 03:37, David Conrad wrote:
Shifting the NAT to end system removed the objection to NAT, tho
it's not entirely clear why. Shifting NAT to the end system also
happened to simplify the entire solution as well.
Except for the part about having to rewrite all existing
On 16-Oct-2005, at 10:27, John Reilly wrote:
On Sat, 2005-10-15 at 22:02 -0700, David Conrad wrote:
I _really_ wish people would stop saying 'unlimited' or 'almost
infinite' when talking about IPv6 address space. It simply isn't
true, even in the theoretical sense, and particularly given
# The problem with that (and many premises) is that we need to remember these
# arguments and foreseen problems were all dreamed up 10 or so years ago.
# The status of everyone's network, everyone's business needs and everyone's
# network design (and capabilities) were drastically different that
How about something like this.
A chunk of ipv6 space is carved off. This is assigned to multihoming
desiring sites.
All routers {can | should } filter this space from their tables
completely by default - except the single prefix covering the entire space.
A customer with a prefix
GSE also has a direct impact on all implementations (e.g., only use
the identifier bits in the TCP pseudo-header, so that is also an all-
implementations change. Further, that is a flag day, worldwide, even
for non-multi-homed sites.
a flag day only for the very small number of ipv6
On Sun, 2005-10-16 at 11:08 -0400, Joe Abley wrote:
Am I mistaken in thinking that if shim6 (or something like it) did
exist, that portable address space could be allocated to everyone
(maybe
with a different allocation policy?) to be used as (shim6)
identifiers.
Yes, you're
# ...
#
# Obviously, some of the disadvantages of such an approach would be that it
# would require both ends to play and end users wouldn't be able to
# traceroute. I'm sure there are many other disadvantages as well. ...
ok, so here's the problem. we don't have what the iab thinks of as
# ...
#
# You are missing the point.
#
# Currently multihomed sites have multiple path entries in the routing table
# for a specific multihomed prefix.
#
# Instead of having multiple paths, you would have multiple location records
# in DNS. (Which are A records and any possible reordering by
On Sun, 16 Oct 2005 10:55:38 EDT, Joe Abley said:
Thought experiment: how many different software vendors need to
change their shipping IPv6 code in order for some new feature like
shim6 to be 80% deployed in the server and client communities of hosts?
I'm thinking it's probably less
On Sun, 16 Oct 2005, Simon Leinen wrote:
Note that not all Cisco routers use process switching for 6to4 tunnel
encap/decap (which is really just IPv6-in-IPv4). Catalyst 6500/7600
OSR with PFC-3 (Sup32/Sup720) do this in hardware.
And for dual-stack organizations using these at the borders,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 16-Oct-2005, at 16:20, [EMAIL PROTECTED] wrote:
On Sun, 16 Oct 2005 10:55:38 EDT, Joe Abley said:
Thought experiment: how many different software vendors need to
change their shipping IPv6 code in order for some new feature like
shim6 to be
On 16-Oct-2005, at 11:08, Joe Abley wrote:
Yes, you're mistaken. The locator identifier is chosen from the
host's pool of upper-layer identifiers.
Oops -- I meant the upper-layer identifier is chosen from the host's
pool of locators. Must Not Post Before Coffee.
Joe
there would seem to be two paths here.
the one we are currently walking has more and more complexity
to try to deal with the lack of reality-based design in v6.
every step, instead of making things simpler, adds more
complexity to deal with the mistakes of old narrow decisions.
consider an
--- Randy Bush [EMAIL PROTECTED] wrote:
so, if we had a free hand and ignored the dogmas,
what would we
change about the v6 architecture to make it really
deployable
and scalable and have compatibility with and a
transition path
from v4 without massive kludging, complexity, and
long
On Sat, 15 Oct 2005, Tony Li wrote:
I don't want to speak for Daniel, nor other operators really, but a
solution that doesn't allow an operator to traffic engineer
internally or
externally is just not workable. For the same reasons quoted in
your other
messages to me: Increased
On Sun, 16 Oct 2005, Susan Harris wrote:
there is no hope in having operators explain to ietf that the current path
is fruitless? certainly they can be made to see the light, yes?
you have not spent much time with the ivtf, have you?
Actually Chris has been extremely active in the
Okay, I'll bite - If I were king, here's what I'd want
to see:
[ changes to current policies, not architecture, elided ]
let's first agree on some goals
o really big address space, not the v6 fixed 32 bit
limited game. (old dogs will now bay for variable
length, aroo!)
o a
o really big address space, not the v6 fixed 32 bit
s/32/64/
sorry
On Sun, Oct 16, 2005 at 05:20:12PM -1000, Randy Bush wrote:
Okay, I'll bite - If I were king, here's what I'd want
to see:
[ changes to current policies, not architecture, elided ]
let's first agree on some goals
o really big address space, not the v6 fixed 32 bit
limited
On 17/10/05, David Barak [EMAIL PROTECTED] wrote:
I'd change the allocation approach: rather than give
every customer a /64, which represents an IPv4
universe full of IPv4 universes, I'd think that any
customer can make do with a single IPv4-size universe,
and make the default end-customer
On Sun, 16 Oct 2005, Mikael Abrahamsson wrote:
Think in the future, do we really want routers that'll handle millions of
prefixes and hundreds of thousands of AS numbers, just because people want
resiliance? If this can be solved on the end-user layer instead, it's more
you are getting
o a routing system which has the ability to scale really
well in the presence of fewer and fewer nodes (think
sites) where out-degree == 1
sure... maybe. is there the presumption of e2e here?
i think so, for various valies of e2e
o mobility
process mobility? latency tolerent?
On Mon, 17 Oct 2005, Christopher L. Morrow wrote:
you are getting these anyway, thank network convergence for that... or
curse it, your call. things like 2547 'vpn' and the like are driving
prefix numbers up regardless of what the Internet is doing. Hardware
will be required to handle
On Mon, 17 Oct 2005, Mikael Abrahamsson wrote:
On Mon, 17 Oct 2005, Christopher L. Morrow wrote:
you are getting these anyway, thank network convergence for that... or
curse it, your call. things like 2547 'vpn' and the like are driving
prefix numbers up regardless of what the Internet
46 matches
Mail list logo
