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
is trying to send is that they want this, and not
IPv6 as it stands today, then that's the message that should be sent,
without reference to shim6.
Tony
How is a split between locator / identifier any different logicaly from
the existing ipv4 source routing?
I thought that got dead
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
to the clients and
servers that chose to implement it, however this is no less than the
change required for IPv6 which some hoped would solve the multihoming
problem (possibly defined as scalably supporting network topology change
without sessions being interrupted).
Long story short, seperating
is not making its own path selection
decisions.)
Of course support of this new protocol would be limited to the clients and
servers that chose to implement it, however this is no less than the
change required for IPv6 which some hoped would solve the multihoming
problem (possibly defined
multiple IPv6 addresses. So if a timeout occurs
to the last used address, you can try another and try to resume the
communication.
So if the web-server has two different IP:s (from two different
providers), both would be in DNS (preferrably) and the TCP session would
be established with one
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
: Re: IPv6 news
[EMAIL PROTECTED] (David Conrad) writes:
On Oct 15, 2005, at 3:27 PM, Tony Li wrote:
When we explored site multihoming (not rehoming) in the ways that
you seem to suggest, it was effectively a set of coordinated NAT
boxes around the periphery of the site. That was rejected
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
implementations to take full advantage of the technology.
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 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
that long ago.
#
# It's a solution that made sense for far different reasons when it was
# created then it makes sense for now.
nope. the problems we're discussing on this thread were all identified ten
years ago but ipv6 got standardized in spite of the warnings. ipv6 as it is
now specified never
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
a supreme court
nominee who gets an inevitable question about roe-v-wade and their knee jerks
and they say i support the constitution.
so even though NAT is here to stay and firewalls are here to stay and proxies
are here to stay and most ipv6 deployment by the end of its useful lifetime
will have
# ...
#
# 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
-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
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
allocation a /96.
I personally am in favor of reducing minimum allocations like this -
and as was discussed quite extensively in the botnet of toasters and
microwave ovens when you ipv6 enable the lot thread a few weeks back,
it usually ends up that there's just one host in a /48 or /64 so
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?
platform that'll do IPv6 and MPLS,
how much difference would it be if you only had to support 16000 labels
and 16000 IPv6 prefixes, rather than 2 million?
Then of course I guess the argument can be made to put everything on MPLS
to avoid the core knowing about anything but outer labels.
--
Mikael
in the MPLS case).
'core' doesn't matter so much, somewhere there has to be this knowledge...
Perhaps you'll get lucky with some 'edge' devices not having to know about
every destination, but I think that might be more rare than you'd like.
So if you're building a 100G capable platform that'll do IPv6
?
had ietf killed back when there were
effectively zero ipv6 hosts on the 'net, and paid the apparently-
high A6
complexity penalty, we'd be talking about something else by now.
Yeah, like why didn't the Internet work anymore. A6 was simply a
broken idea. It might have limped along
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?
randy
I don't think users need to be charged any extra for IPv6 if it runs in the
same pipe as their actual IPv4 one.
Do we charge to our customers when we solve a bug or problem in our network
?
IPv6 was invented to solve a bug in IPv4: The lack of enough addresses.
Of course, now IPv6 could bring
When I suggest to my customers to move to IPv6, I explicitly tell them that
planning is very important:
1) Initially (in some cases), your equipment may not have native support for
the core/access networks. Not a problem, when you upgrade your network for
other reasons (line cards, new IPv4
On 14/10/2005, at 3:35 AM, Peter Lothberg wrote:
Here's a challange, have NTP server attached directly to
a good clock and a IPv6 network.
Is there anyone who can talk to it using IPv6 on the Nanog list?
(Time20.Stupi.SE, 2001:0440:1880:1000::0020)
yoyo$ ntpdate -q 2001:0440:1880:1000
But I have also to admit that I'm shocked how few folks have the balls
(or is it lazyness?) to express their opinion on IPv6 multihoming in the
public, on the established fora for that stuff.
The probably got bored of having it doesn't scale shouted at them
Almost zero feedback from
than
100mbps are usually the relays used outbound by large content delivery
networks (the relay used by newszilla6.xs4all.nl (free binary
newsserver) comes to my mind).
This is totally manageable with Cisco routers regardless the constant
bickering about the suboptimal Cisco (IPv6) performance
table
growth wasn't possible, evil because it locked customers into their providers,
entrenched the existing large providers against future providers, and made it
hard or impossible for the average endusing company to multihome. so, when
IPv6 was chosen and was more evil in that way, i was mystified
the allocation
policy).
FWIW, my current IPv6 assignment is PI to a degree (where P == my
first hop IPv4 provider), I can change this first hop IPv4 provider
to any other provider within my country and still retain my IPv6
assignment.
That kind of PI at least meets a lot of my needs
FWIW, my current IPv6 assignment is PI to a degree (where P == my
first hop IPv4 provider), I can change this first hop IPv4 provider
to any other provider within my country and still retain my IPv6
assignment.
it sounds as if you have the mythical separation of locator
and identifier
-broker, which is mine to use long as ISPs here do not
deploy IPv6 ;).
one problem with 6to4 is that having all traffic go through
gateways will not scale well. to support v6-only folk, either the
number of 6to4 gateways will need to approach the number of dfz
routers, the dfz routers will run 6to4
are going to say IPv6 has something
almost
like NAT, only different.
you know... shim6 could make 'source address' pointless, you COULD
just do
NAT instead :) or do shim6 which looks like NAT ... if you don't
get the
host auth parts correct/done-well you might even be able to send
traffic
On Fri, 14 Oct 2005, Tony Li wrote:
But I think the discussion is mood. IETF decided on their goal, and
it's superfluous trying to change that. While watching shim6 we carry
on hoping that we'll get IPv6 multihoming going in the conventional,
proven, working, feature-complete way we're
On Sat, Oct 15, 2005 at 08:36:29PM +0930, Mark Prior wrote:
It might be closer if we turned up IPv6 with Sprint but are they
native yet?
Nope.
http://www.nanog.org/mtg-0405/augmentation.html and
http://www.nanog.org/mtg-0405/pdf/rockell.pdf
Although it's dated, I don't
On Sat, 15 Oct 2005 00:22:15 -0500
Nicholas Suan [EMAIL PROTECTED] wrote:
Daniel Roesen wrote:
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
Perhaps that middle ground is a mix of these 2 things?
Perhaps. But what we currently seem to believe is that current
routing table growth is dominated by traffic engineering and
multihoming. If future routing is to scale better than today, then
we need some strong forces that push
So the IETF identified 4 reasons to multihome. Of those 4, shim6
ignores at least 2 of them (operational policy and cost), and so
far as I can see glosses over load sharing.
If you have a solution that satisfies all requirements, you should
contribute it. Shim6 is indeed a partial
the attributes of conventional BGP multihoming.
Please don't lay words into my mouth I didn't say.
Those are exactly the words that you used in your message. I quote:
While watching shim6 we carry
on hoping that we'll get IPv6 multihoming going in the conventional,
proven, working, feature
that there would be any
proposals which would meet all the items in the document if they had
been wrapped in MUSTs and SHOULDs. As the abstract says:
This document outlines a set of goals for proposed new IPv6 site-
multihoming architectures. It is recognised that this set of goals
On Oct 15, 2005, at 3:29 PM, Tony Li wrote:
So the IETF identified 4 reasons to multihome. Of those 4, shim6
ignores at least 2 of them (operational policy and cost), and so
far as I can see glosses over load sharing.
If you have a solution that satisfies all requirements, you should
On Fri, 14 Oct 2005, Ben Butler wrote:
Date: Fri, 14 Oct 2005 17:32:10 +0100
From: Ben Butler [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: RE: IPv6 news - newbie
[ ... ] I have no idea whether there is a market for v6 connectivity
/ hosting amongst UK businesses, I guess we will find
I don't have an acceptable solution... however, I am getting tired
of shim6 being pushed as *the* solution to site rehoming, when at
best it's an end node rehoming solution.
Well, sorry. When we explored site multihoming (not rehoming) in the
ways that you seem to suggest, it was
Tony,
On Oct 15, 2005, at 3:27 PM, Tony Li wrote:
When we explored site multihoming (not rehoming) in the ways that
you seem to suggest, it was effectively a set of coordinated NAT
boxes around the periphery of the site. That was rejected quite
quickly.
What were the reasons for
On Sat, 15 Oct 2005, Tony Li wrote:
The operational community needs to reach consensus on what its
priorities are. We fought the CIDR wars to keep the routing
subsystem working and the operational community were the primary
backers of that. To not support scalable multihoming is to
[EMAIL PROTECTED] (David Conrad) writes:
On Oct 15, 2005, at 3:27 PM, Tony Li wrote:
When we explored site multihoming (not rehoming) in the ways that
you seem to suggest, it was effectively a set of coordinated NAT
boxes around the periphery of the site. That was rejected quite
Jordi,
On Oct 15, 2005, at 2:09 AM, JORDI PALET MARTINEZ wrote:
I don't think users need to be charged any extra for IPv6 if it
runs in the
same pipe as their actual IPv4 one.
If IPv6 is tunneled through IPv4 in such a way that the ISP doesn't
have to do anything special, then I suspect
.
Not reducing the information means either having the same number of
routing table entries as the number of multihoming sites or enforcing some
kind of theoretical heirarchical structure (many of the original IPv6
papers had this pipe dream spelled out for how to handle multihoming)
either based
On Oct 15, 2005, at 9:08 PM, Paul Vixie wrote:
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.
Hmm.
Is VJ compression considered a violation of the end-to-end
are they not, as
they apparently didn't reserve any funds for upgrades of their network,
nor didn't take IPv6 along in the last 10 years of hardware cycles, thus
clearly having played dumb for the last 10 years, how should their
customers suddenly have to cough up to the stupidity of not being able
to run
On Thu, Oct 13, 2005 at 01:32:32PM -0500,
Mike Hyde [EMAIL PROTECTED] wrote
a message of 3 lines which said:
On the subject of ipv6, is there currently any way to multi-home
with IPv6 yet?
RFC 4177: Architectural Approaches to Multi-homing for IPv6 (five
approaches, including at least one
deployments all use Junipers (for
their IPv6), not Ciscos (with a few exceptions - Verio?). Don't know
wether that's true for ASPAC folks too - can someone comment?
One might conclude a thing or two from that - or not.
Best regards,
Daniel
--
CLUE-RIPE -- Jabber: [EMAIL PROTECTED] -- [EMAIL
On Thu, 13 Oct 2005 [EMAIL PROTECTED] wrote:
Somehow, I don't think anything that Abilene does is going to fix Jordi's
routing. From where *you* are, do *you* have a path to
2001:0440:1880:1000::0020
that *doesn't go through Japan? If so, what does your path look like?
# traceroute6
Blech. :) (For comparison, here's the IPv4 traceroute:
Very interesting. From the east coast your IPv4 traffic
goes to Virginia and then to the UK. But your IPv6 traffic
goes to Atlanta, Houston, LA and across the Pacific.
Is this due to someone's misconfiguration of weights?
--Michael
I told them dudes to forklift their network is hardly productive.
IPv6 is not a forklift upgrade.
Showing, if folks can't find it themselves, that there is a business
case
that would justify a few million dollar upgrade is...
Again, it is cheaper to ease into IPv6 rather than waiting until
There are a few interesting questions here (partially rhetorical):
And also:
Should your company be preparing to operate v6 services
at all? Popular opinion is that when the automobile was
invented, all buggy manufacturers shut down. This is
not true. http://www.liveryone.net/
IPv6 is one
Brandon Ross [EMAIL PROTECTED] writes:
On Thu, 13 Oct 2005 [EMAIL PROTECTED] wrote:
I'm sure that there will be a frantic scramble, but I don't
expect it to last long enough for an IPv4 black market to
form.
There's already a black market in IPv4. I've seen plenty of offers to
buy
website-access
for free via IPv6..
--
Sabri
please do not throw salami pizza away
[EMAIL PROTECTED] (Peter Lothberg) writes:
Is there anyone who can talk to it using IPv6 on the Nanog list?
(Time20.Stupi.SE, 2001:0440:1880:1000::0020)
[sa:amd64] ntpq -p 2001:0440:1880:1000::0020
remote refid st t when poll reach delay offset jitter
clients are already paying them at them moment are they not, as
they apparently didn't reserve any funds for upgrades of their network,
nor didn't take IPv6 along in the last 10 years of hardware cycles, thus
clearly having played dumb for the last 10 years, how should their
silly me... I forgot
wait for a popular adult-content-provider offering website-access
for free via IPv6..
that'd fall into my 1 month ago questions about: Why won't a large
content provider or 3 light v6 versions of their services? questions :)
builds by anyone large.
Just wait for a popular adult-content-provider offering website-access
for free via IPv6..
Why ? Are you implying that there is unlimited free IPv6 bandwidth ? If not,
why would they do that ?
If so, I don't do porn, but I would be highly interested in free bandwidth. I
On Thu, Oct 13, 2005 at 03:50:17PM -0400, [EMAIL PROTECTED] wrote:
On Thu, 13 Oct 2005 21:44:23 +0200, Jeroen Massar said:
Kick Abilene to not be so silly and get some real transits. Then again
Abiline is educational and those networks seem to have very nice (read:
overcomplex) routing
that is their current solution :)
The larger EU/US ISPs that have real deployments all use Junipers (for
their IPv6), not Ciscos (with a few exceptions - Verio?). Don't know
wether that's true for ASPAC folks too - can someone comment?
We're using both cisco and juniper in Verio for our IPv6
On Fri, Oct 14, 2005 at 10:17:51AM -0400, Marshall Eubanks wrote:
Dear Marshall,
Just wait for a popular adult-content-provider offering website-access
for free via IPv6..
Why ? Are you implying that there is unlimited free IPv6 bandwidth ?
Nope.
If not, why would they do
On 14-Oct-2005, at 10:13, Christopher L. Morrow wrote:
Yep, there is no multihoming, but effectively, except for the BGP
tricks
that are currently being played in IPv4 there is nothing in IPv4
either.
But one won't need to upgrade a Tier 1's hardware to support
shim6, as
shim6 is:
1)
customers and so, thus they can easily get a IPv6 prefix from their
favourite RIR. Thus they get, say a /32.
Now this ISP has a large webfarm in the US. They have a very small one
in say, Taiwan. In IPv4, this would mean: chunk up your PA and simply
announce them in /20's or whatever is comfortable
On Fri, Oct 14, 2005 at 10:57:59AM -0400, Joe Abley wrote:
The big gap in the multi-homing story for v6 is for end sites, since
those are specifically excluded by all the RIRs' policies on PI
addressing right now. Shim6 is intended to be a solution for end sites.
But isn't a solution for
Should your company be preparing to operate v6 services
at all? Popular opinion is that when the automobile was
invented, all buggy manufacturers shut down. This is
not true. http://www.liveryone.net/
A buggy company founded in 1972?
What kind of comparison are you trying to make? Wait 75
On 14-Oct-2005, at 11:27, Daniel Roesen wrote:
On Fri, Oct 14, 2005 at 10:57:59AM -0400, Joe Abley wrote:
The big gap in the multi-homing story for v6 is for end sites, since
those are specifically excluded by all the RIRs' policies on PI
addressing right now. Shim6 is intended to be a
trying to change that. While watching shim6 we carry
on hoping that we'll get IPv6 multihoming going in the conventional,
proven, working, feature-complete way we're used to... until IETF
perhaps at one point in time realize that they are designing a solution
which misses the stated requirements
Dear Sabri;
On Fri, 14 Oct 2005 16:34:19 +0200
Sabri Berisha [EMAIL PROTECTED] wrote:
On Fri, Oct 14, 2005 at 10:17:51AM -0400, Marshall Eubanks wrote:
Dear Marshall,
Just wait for a popular adult-content-provider offering website-access
for free via IPv6..
Why ? Are you
***
Your mail has been scanned by InterScan VirusWall.
***-***
One thing i find promising/good: Lots of people here sent their v6
traces to the list, so it's not just a few random geeks messing with v6
as much anymore, it's there.
- jared
Hi,
Well
i'd like to see the island of IPv4 being tunneled over a native IPv6
network... not the IPv4 ntworks turned off. For the good folks
who NAT today, there should be a minor change @ the NAT
--bill
Thus spake Mike Leber [EMAIL PROTECTED]
On Thu, 13 Oct 2005, Michael Greb wrote:
I can't speak for the others but he.net doesn't seem to interested in
customers making use of their dual stack network. We looked into
getting IPv6 space from them to go with our IPv4 assignments for a
couple
On Fri, 14 Oct 2005 10:21:20 EDT, Jared Mauch said:
Mine does not:
punk:~/Desktop traceroute6 2001:0440:1880:1000::0020
traceroute to 2001:0440:1880:1000::0020 (2001:440:1880:1000::20) from
2001:418:3f4:0:20e:a6ff:febf:a5ca, 30 hops max, 16 byte packets
1 2001:418:3f4::1
On Fri, 14 Oct 2005 10:45:14 CDT, Sam Hayes Merritt, III said:
A buggy company founded in 1972?
What kind of comparison are you trying to make? Wait 75 years
after your business is gone and then start anew?
No, they were 25 years *ahead* of everybody else. Remember the .com bubble,
where
On Fri, Oct 14, 2005 at 02:15:20PM -0400, [EMAIL PROTECTED] wrote:
Interesting. :) That's the first one I've seen that a sprintv6.net address
isn't at
hop number 3 or so (indicating that the person is basically directly
connected to
sprintv6.net) and also doesn't take a loop through
Joe (or anyone else),
On Oct 14, 2005, at 7:57 AM, Joe Abley wrote:
The big gap in the multi-homing story for v6 is for end sites,
since those are specifically excluded by all the RIRs' policies on
PI addressing right now. Shim6 is intended to be a solution for end
sites.
Since shim6
for the large percentage of customers that don't care,
then that may be the direction we need to take.
XP already comes with v6; all you have to do is Start-Run-ipv6 install.
Vista will just change things from default off to default on. IT
departments can handle the logistics of this once their network
Thus spake Kevin Loch [EMAIL PROTECTED]
Randy Bush wrote:
and don't you just love the suggestions of natting v6?
No, but I would like to see consumer routers support rfc3068
(automatic 6to4 tunneling) by default when there is no native IPv6
access service.
If we could convince manufacturers
BTW, as I read it, SHIM6 requires not only modification to ALL nodes at the
site,
but, modification to ALL nodes to which the node needs reliable
connectivity.
In other words, SHIM6 is not fully useful until it is fully ubiquitous in
virtually
all IPv6 stacks.
Owen
--On October 14, 2005 11:48
On 14-Oct-2005, at 14:48, David Conrad wrote:
On Oct 14, 2005, at 7:57 AM, Joe Abley wrote:
The big gap in the multi-homing story for v6 is for end sites,
since those are specifically excluded by all the RIRs' policies on
PI addressing right now. Shim6 is intended to be a solution for
in
virtually all IPv6 stacks.
Which is not to say that there is no value in a non-ubiquitous
deployment -- rather, the value will grow as deployment proceeds.
Joe
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (Darwin)
iD8DBQFDUAYT/f+PWOTbRPIRAoZGAJ91IkqDyktDQjBPE0fXBhqXKYtDRwCfYMTq
On Fri, Oct 14, 2005 at 03:19:27PM -0400, Joe Abley wrote:
On Oct 14, 2005, at 7:57 AM, Joe Abley wrote:
Since shim6 requires changes in protocol stacks on nodes, my
impression has been that it isn't a _site_ multihoming solution,
but rather a _node_ multihoming solution. Is my
On Fri, 14 Oct 2005 [EMAIL PROTECTED] wrote:
Since shim6 requires changes in protocol stacks on nodes, my
impression has been that it isn't a _site_ multihoming solution,
but rather a _node_ multihoming solution. Is my impression incorrect?
There is no shortage of rough corners to file
On Fri, Oct 14, 2005 at 07:27:37PM +, [EMAIL PROTECTED] wrote:
the kicker here is that the applications then need some
serious smarts to do proper source address selection.
Nope. The ULID is supposed to be static, globally unique. Just not
globally routed. Seperating topology
On Fri, Oct 14, 2005 at 12:33:51PM -0700, william(at)elan.net wrote:
On Fri, 14 Oct 2005 [EMAIL PROTECTED] wrote:
Since shim6 requires changes in protocol stacks on nodes, my
impression has been that it isn't a _site_ multihoming solution,
but rather a _node_ multihoming solution. Is my
801 - 900 of 2069 matches
Mail list logo
