Tony writes:
The space
identified in RFC 1918 was set aside because people were taking
whatever
addresses they could find in documentation.
There is a long and "interesting" history here, but it isn't directly
relevant
to this discussion. I think it would be valuable to focus the
discussion
Ted Hardie wrote:
> There is a long and "interesting" history here, but it isn't
> directly
> relevant
> to this discussion. I think it would be valuable to focus the
> discussion on Site Local,
> rather than on RFC 1918 space.
The reason for bring 1918 into the discussion is that prior to N
On Wed, 2003-03-26 at 16:38, Tony Hain wrote:
> Ted Hardie wrote:
> > I think you may underestimate how much trouble this might cause in
> > applications.
> > As Dave Crocker noted in response to Margaret Wasserman's
> > presentation to the APPs Open Area meeting, applications have
> > been des
At 1:38 PM -0800 3/26/03, Tony Hain wrote:
I am not arguing that every app need to know about topology. If this is
such a big deal, we should simply fix the API so that by default it only
returns global scope addresses, then add a new function for those apps
that are interested in the limited scope
Michael Mealling wrote:
> Its not that 'we don't want to change because its to much
> work'. Its that the Internet architecture assured us that the
> hour glass model applied, that the network topology would
> remain abstracted within what to us is an opaque address
> space. One of the number o
On Wednesday, March 26, 2003, at 01:38 PM, Tony Hain wrote:
Ted Hardie wrote:
There is a long and "interesting" history here, but it isn't
directly
relevant
to this discussion. I think it would be valuable to focus the
discussion on Site Local,
rather than on RFC 1918 space.
The reason for bring
> Ted Hardie wrote:
> I think we then to consider whether the current need
> is for: "non-routed globally unique space" or for
> something else. If the answer is "non-routed globally
> unique space", then the follow-on question is "Why not
> get globally unique space and simply decide not to
> rou
Michel,
I don't think something needs to be provider independent
to fit this bill. Getting a slice of the global address space from
some provider and choosing not route a portion of it (even
if that portion is 100%) seems to me to create "non-routed
globally unique space". Are you concerned that
Ted,
What happens when you change providers?
Rgds,
-drc
On Wednesday, March 26, 2003, at 04:01 PM, Ted Hardie wrote:
Michel,
I don't think something needs to be provider independent
to fit this bill. Getting a slice of the global address space from
some provider and choosing not route a porti
Hi David,
Provider of what? Note that if a provider of address space is not
routing the addresses involved, they have few or no performance
responsibilities in the arena. They don't even need to polish and
regrind
the digits periodically; they just go. It seems unlikely to me
personally that
John C Klensin wrote:
> ...
For most of the cut section, consider that while 'good practice' says to
use names, reality is that too many apps still grab the address for
random reasons.
> But, obviously, I'm not understanding something. Could you
> explain?
There is a lot of noise about treatin
Ted,
On Wednesday, March 26, 2003, at 05:03 PM, Ted Hardie wrote:
If you were using some of an allocated portion as routable addresses
and some as unrouted addresses, you might be forced to change the
unrouted addresses as a consequences of choosing someone new to carry
the traffic from t
On Wednesday, March 26, 2003, at 05:40 PM, David Conrad wrote:
Ted,
On Wednesday, March 26, 2003, at 05:03 PM, Ted Hardie wrote:
If you were using some of an allocated portion as routable addresses
and some as unrouted addresses, you might be forced to change the
unrouted addresses as a consequ
Or what if there is no provider (as in default addresses used by a
software vendor)?
-andy
David Conrad wrote:
Ted,
What happens when you change providers?
Rgds,
-drc
On Wednesday, March 26, 2003, at 04:01 PM, Ted Hardie wrote:
Michel,
I don't think something needs to be provider indepen
From the reading of the draft, it would appear that much of the pain
for applications with SL is caused because the apps violated the contract.
Actually, its a wonder any of these would work in v6 at all given the
description of the problem (address leaks).
-andy
Michael Mealling wrote:
Its not
At 08:40 PM 3/26/2003, David Conrad wrote:
Ted,
On Wednesday, March 26, 2003, at 05:03 PM, Ted Hardie wrote:
If you were using some of an allocated portion as routable addresses
and some as unrouted addresses, you might be forced to change the
unrouted addresses as a consequences of choos
Tony,
The specifics of the site local issue should be debated on the IPv6 WG
list, not on the global IETF list. Let me however respond to your point
regarding the quality of the debate, as I was the note taker during that
session.
My notes record that 22 separate speakers took part to this debate
Thus spake "Christian Huitema" <[EMAIL PROTECTED]>
> The specifics of the site local issue should be debated on the IPv6 WG
> list, not on the global IETF list. Let me however respond to your point
> regarding the quality of the debate, as I was the note taker during that
> session.
Issues most of
--On onsdag, mars 26, 2003 17:40:23 -0800 David Conrad
<[EMAIL PROTECTED]> wrote:
Ted,
On Wednesday, March 26, 2003, at 05:03 PM, Ted Hardie wrote:
If you were using some of an allocated portion as routable addresses
and some as unrouted addresses, you might be forced to change the
un
Daniel Senie wrote:
> No. It does not imply NAT. It implies traffic to hosts which
> are used for purposes which do not communicate to the public
> network.
>
> Could we PLEASE leave NAT out of the equation? Not all hosts
> in the world want or need to be connected outside of the
> corporate
Could we PLEASE leave NAT out of the equation? Not all hosts in the
world want or need to be connected outside of the corporate network
they belong to.
true. but they still need unique addresses.
> Its not that 'we don't want to change because its to much work'. Its
> that the Internet architecture assured us that the hour glass model
> applied, that the network topology would remain abstracted within what
> to us is an opaque address space. One of the number one reasons its so
> easy for
> Yes, there was mention of "site local as a license to NAT", but
> there where many other arguments: leakage through IP, DNS or
> application; the lack of practicality of several restrictive models
> for site locals; the possibility or not to use other solutions for
> isolated sites; and the compl
> This is so typical of the modern IETF -- 102 people were persuaded
> by handwaving arguments that "something bad might happen" if a new
> and useful technique were deployed, and they are being allowed to
> overwhelm the 20 who were willing to dig in and find and solve any
> real problems.
Well M
> From: "Louis A. Mamakos" <[EMAIL PROTECTED]>
> The Internet architecture never gave the end system some mechanism to
> help it make this binding decision when trying to communicate with
> non-local peers.
> ...
> There was no protocol to ask the network "which of address
[Folks who are not interested in the details of the IPv6 WGs discussion of
site-local addressing can just hit 'd' now.]
Hi Tony,
There is a lot of noise about treating SL special, but as you note an
application can ignore that a 1918 address is somehow different from any
other address. If an appli
Margaret Wasserman wrote:
> [Folks who are not interested in the details of the IPv6 WGs
> discussion of site-local addressing can just hit 'd' now.]
Still true. For the record, I agree that debate on this SL issue should
be on the WG list.
>
> Hi Tony,
>
> >There is a lot of noise about treat
Hi Matt,
This is so typical of the modern IETF -- 102 people were persuaded
by handwaving arguments that "something bad might happen" if a new
and useful technique were deployed, and they are being allowed to
overwhelm the 20 who were willing to dig in and find and solve any
real problems.
I do no
Margaret Wasserman wrote:
> No active IPv6 WG participant (whether or not he attends IETF
> meetings) could credibly claim that he was unaware that this
> discussion was taking place,
The discussion has been about potential usage limitation, or BCP's
identifying application issues. The point of d
On Thu, Mar 27, 2003 at 06:51:01PM -0500, Keith Moore wrote:
>
> > I suspect that most people there, who voted for
> > the elimination of site-locals, would still be
> > favor of enabling the features that site-locals
> > were intended to offer. Perhaps the majority
> > position could be paraphra
At 03:49 PM 3/27/2003 -0800, Tony Hain wrote:
Margaret Wasserman wrote:
> No active IPv6 WG participant (whether or not he attends IETF
> meetings) could credibly claim that he was unaware that this
> discussion was taking place,
The discussion has been about potential usage limitation, or BCP's
id
Margaret Wasserman wrote:
> There have been people calling for the complete removal of
> site-local addressing all along.
>
> And, elimination/deprecation was quite clearly raised as an
> option in Atlanta. At that time, we called for opinions on
> the following
> options: elimination, "limit
Hi Tony,
I am not sure what your point is exactly, or why you want to make
this point on the full IETF list...
Are you suggesting that the options open to the IPv6 WG should
be constrained by the drafts that Bob and I list on the agenda?
By Thursday, the agenda had actually changed to a joint pres
Ted,
>>> Ted Hardie wrote:
>>> I think we then to consider whether the current need
>>> is for: "non-routed globally unique space" or for
>>> something else. If the answer is "non-routed globally
>>> unique space", then the follow-on question is "Why not
>>> get globally unique space and simply d
Michel,
What you say is possible, and has happened. But dumb things happen.
Those dumb things could happen with non site-local addresses as well.
But look. Ultimately I think we as a community do need to own up to
better tooling, which can lead to better expectations. Also, I don't
see any
The reason for bring 1918 into the discussion is that prior to NAT,
there was a market demand for private address space.
sometimes the market is misled by vendors who want to sell planned
obsolesence. NAT is the perfect example.
since it is in fact the violation of
the layering by the apps that has created some of the mobility and
renumbering challenges.
uh, no. DNS is not a layer. it is a naming service. it's not the
only way that an app can get an IP address, and never has been.
Ignoring the format of addresses has worked well for 1918 addresses
(loathsome as they might be) because the assumption is that filtering
(so that they don't leak onto the public network) is the
responsibility of anything that connects a 1918 network to the public
Internet.
but this assumption
There is a lot of noise about treating SL special, but as you note an
application can ignore that a 1918 address is somehow different from
any
other address. If an application were to do the same and just use a SL
as any other address, it will work just fine until one of the
participants is on the
Eliot,
> Eliot Lear wrote:
> What you say is possible, and has happened. But dumb
> things happen. Those dumb things could happen with non
> site-local addresses as well.
More limited, that's the point. Not perfect, but better than unregulated
anarchy. However, between a network design that does
On Thu, Mar 27, 2003 at 05:48:44PM -0800, Christian Huitema wrote:
>
> My Windows-XP laptop currently has 14 IPv6 addresses, and 2 IPv4
> addresses. The sky is not falling.
Except of those 14 some seven(?) are RFC3041 addresses, which break a
number of applications... so there are some clouds in
> I suspect that most people there, who voted for
> the elimination ...
At my first IETF meeting I received a T-Shirt, courtesy of Marshall
Rose, I believe, that said "We reject kings, presidents and voting..."
The real tragicomedy of this situation is that someone considered it
fitting and prope
> Way back in the dark ages, it was not uncommon to have multi-homed
> HOSTS: one leg on the ARPANET, the other arm on some local LAN
> segment. The application and/or network stack on that machine was
> left with a decision to choose which interface address it ought to
> use when binding some loc
> This is so typical of the modern IETF -- 102 people were persuaded
> by handwaving arguments that "something bad might happen" if a new
> and useful technique were deployed, and they are being allowed to
> overwhelm the 20 who were willing to dig in and find and solve any
> real problems.
uh, no
Hello folks,
I was there, and it wasn't so black and white.
It's not fair to characterize it so.
I suspect that most people there, who voted for
the elimination of site-locals, would still be
favor of enabling the features that site-locals
were intended to offer. Perhaps the majority
position c
> You are mixing cause and effect. In IPv4 the vast majority of nodes
> are limited to a single address at a time.
Well, I don't know about windows boxes, but real operating systems have
supported virtual hosting in IPv4 for many years. Having multiple
addresses on a node, even a node with a sin
> I suspect that most people there, who voted for
> the elimination of site-locals, would still be
> favor of enabling the features that site-locals
> were intended to offer. Perhaps the majority
> position could be paraphrased as "against site-local,
> but sorry to see them go".
I agree. I thi
Margaret Wasserman wrote:
As you know, I was in favor of setting aside a prefix (FECO::, in fact)
for use as private address space (either on disconnected networks, or
behind NATs), but the consensus of the folks in the IPv6 WG meeting
was to deprecate that prefix altogether. There were several c
On Thu, Mar 27, 2003 at 06:46:10PM -0500, Keith Moore wrote:
> No, it's more than that. SLs impose burdens on hosts and apps.
> SLs break the separation of function between apps and the network that
> is inherent in the end-to-end principle.
Is it safe to assume that the arguments (on either side
> Except of those 14 some seven(?) are RFC3041 addresses, which break a
> number of applications... so there are some clouds in the sky.
3041 may be next on the hit-list. Pretty soon it truly will be
nothing but bigger addresses.
Tim Chown wrote:
> On Thu, Mar 27, 2003 at 05:48:44PM -0800, Christian Huitema wrote:
> >
> > My Windows-XP laptop currently has 14 IPv6 addresses, and 2 IPv4
> > addresses. The sky is not falling.
>
> Except of those 14 some seven(?) are RFC3041 addresses, which
> break a number of application
> > You are mixing cause and effect. In IPv4 the vast majority of nodes
> > are limited to a single address at a time.
>
> Well, I don't know about windows boxes, but real operating systems
have
> supported virtual hosting in IPv4 for many years. Having multiple
> addresses on a node, even a nod
> And in Atlanta we all agreed to take elimination off the list, and it
> has not been discussed since.
what's changed is that we had a chance to look at various ways of limiting
usage of SL, and found that none of them would make SLs tolerable.
> As a side-note, a fifth SL option was presented "out of the blue" in SFO,
> namely exclusive SL/global addressing (one or the other only), which,
> because it was rather a "broken" idea, I think perhaps added to the room
> sentiment that site-locals are broken (rightly or wrongly :)
well, it was
layers above it and a dangerous blow to the hour glass model.
Looking at what is going on in the IETF, I think we are talking about
first aid rather than trying to prevent the blow as such. That happened
along time ago...:-(
But yes, we need to protect the architectural model or discuss a new
Because such thing does not exist, it's called PI and is not available
to IPv6 end-sites. And if it ever is, it will cost money or other
annoyances to obtain.
SLs won't come for free either. Architecture aside, I prefer people
that use a service to pay for it rather than the community as such.
T
To echo the favorable review of Steve's presentation: It's at
http://www.ietf.org/proceedings/01aug/slides/plenary-1/index.html,
and is well worth the few minutes it takes to read/re-read...
Spencer
--- Kurt Erik Lindqvist <[EMAIL PROTECTED]> wrote:
>
> Steve Deering made a wonderful presentatio
On Fri, Mar 28, 2003 at 09:11:07AM -0600, Matt Crawford wrote:
> > Except of those 14 some seven(?) are RFC3041 addresses, which break a
> > number of applications... so there are some clouds in the sky.
>
> 3041 may be next on the hit-list. Pretty soon it truly will be
> nothing but bigger addre
On Thu, 27 Mar 2003 15:31:23 -0500
John Stracke <[EMAIL PROTECTED]> wrote:
> Margaret Wasserman wrote:
>
> > As you know, I was in favor of setting aside a prefix (FECO::, in
> > fact) for use as private address space (either on disconnected
> > networks, or behind NATs), but the consensus of the
David,
let's not mix the problem with provider independent addressspace with
the SL issue. The first needs to be solved anyway, and SLs are not the
answer.
Best regards,
- kurtis -
What happens when you change providers?
Rgds,
-drc
On Wednesday, March 26, 2003, at 04:01 PM, Ted Hardie wro
Keith Moore wrote:
On Thu, 27 Mar 2003 15:31:23 -0500
John Stracke <[EMAIL PROTECTED]> wrote:
Besides, we have three such prefixes, given RFC-1918 and 6to4:
2002:A00::/24, 2002:AC10::/28, and 2002:C0A8::/32.
the same problems exist for these as for SLs.
Right.
we should deprecate these
On Thu, 27 Mar 2003 18:29:22 -0600
John Kristoff <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 27, 2003 at 06:46:10PM -0500, Keith Moore wrote:
> > No, it's more than that. SLs impose burdens on hosts and apps.
> > SLs break the separation of function between apps and the network
> > that is inherent
Tony,
I've been trying to get my mind around the various issues here,
and I keep getting back to the same place, so I think I need to
embarrass myself by making a proposal that I find frightening.
Let's assume, as I think you have suggested, that SL is all
about local addresses and filtering,
John C Klensin wrote:
> Tony,
>
> I've been trying to get my mind around the various issues here,
> and I keep getting back to the same place, so I think I need to
> embarrass myself by making a proposal that I find frightening.
>
> Let's assume, as I think you have suggested, that SL is all
>
On Fri, 28 Mar 2003 14:00:31 EST, "David R. Oran" said:
> Did anybody consider just handing out a /48 (or a bit smaller)
> automagically with each DNS registration?
Routing Table Bloat. If you can figure out how to do this in a CIDR
aggregation context, or otherwise work around the table problem
David R. Oran wrote:
> Did anybody consider just handing out a /48 (or a bit smaller)
> automagically with each DNS registration?
I proposed a couple of times a /32 from which /48 can be requested
for 'private' (never to be connected to the internet) purposes.
I think some others have proposed a
John C Klensin wrote:
> (ii) ISPs impose restrictions on their customers all the time
> and often even enforce them. Many of us consider some of these
> to be desirable (e.g., terms and conditions prohibiting
> spamming) and others less so (e.g., prohibitions against running
> server or peer-p
John C Klensin wrote:
> ... but I am unconvinced that we should make special
> architectural provisions to make it easier to be in the ISP
> business while being clueless.
Isn't that just what we did with MPLS?? ;)
or does that just prove your point? ;))
My arguments are more about acknowledg
John,
> John C Klensin wrote:
> We, or more specifically, the upstream ISP or an RIR, can
> tell the ISP that things will go badly for them if they
> permit un-routable addresses to leak into the public
> Internet. The only difference I can see between what I
> think is your SL address preference
John, mixed bag of nasties here. Routing, addressing, and (of course)
the DNS. More fun than should be legal on a friday afternoon.
Routing: there is a varient here. Think about routing table slots.
If I get one, does it matter what the length of the prefix that I
put in it? There are ot
% David R. Oran wrote:
%
% > Did anybody consider just handing out a /48 (or a bit smaller)
% > automagically with each DNS registration?
%
% I proposed a couple of times a /32 from which /48 can be requested
% for 'private' (never to be connected to the internet) purposes.
% I think some others
Bill Manning [mailto:[EMAIL PROTECTED] wrote:
> % David R. Oran wrote:
> %
> % > Did anybody consider just handing out a /48 (or a bit smaller)
> % > automagically with each DNS registration?
> %
> % I proposed a couple of times a /32 from which /48 can be requested
> % for 'private' (never to
Hi John,
But suppose we really do have enough address space (independent of routing
issues). In that context, is site local just a shortcut to avoid dealing
with a more general problem? Should we have a address allocation policy
that updates the policies of the 70s but ignores the intermediat
Bill Manning wrote:
> Is may be worth noting that RIRs have -NEVER- made presumptions
> on routability of the delegations they make.
Did you just say 69/8 ? :)
If an ISP chooses not to make a specific prefix reachable
it is there 'problem'/policy, not much to do about it.
Also anybo
Which actually poses an interesting question: when should an application
just give up? IMHO, there is only one clear-cut case, i.e. when the
application actually contacted the peer and obtained an explicit
statement that the planned exchange should not take place -- the
equivalent of a 4XX or 5XX
Christian Huitema wrote:
> Well, that is emphatically *NOT* what application developers
> do. They do not just observe that it does not work, they try
> to work around, e.g. routing messages to a different address,
> at a different time, through a third party, or through a
> different protocol.
> From: "Christian Huitema" <[EMAIL PROTECTED]>
> ...
> Well, that is emphatically *NOT* what application developers do.
Speak for yourself.
> Which actually poses an interesting question: when should an application
> just give up? IMHO, there is only one clear-cut case, i.e. when the
> applicat
On Mon, 31 Mar 2003 12:17:44 PST, Eliot Lear said:
> Right up till the point where two companies start communicating with one
> another directly with site-locals. Even if there is a router frob to
> keep the scopes scoped, you can bet it won't be used until someone
> realizes that the above pro
Hi Tony,
At 11:51 AM 3/31/2003 -0800, Tony Hain wrote:
Margaret Wasserman wrote:
> Of course, in the case of site-local addresses, you don't
> know for sure that you reached the _correct_ peer, unless you
> know for sure that the node you want to reach is in your
> site.
Since the address block is
> All things SL is claimed to solve are solveable with unique
> addresses too, as long as you've got enough of them. The rest is
> just simple (perhaps tedious) work that every operations-aware
> person I know of would prefer to madness.
All right, how do you make internal site communications comp
> Let's assume that there is a FooBar server in SiteA. If another
> node in SiteA (NodeA) is communicating via a multi-party application
> to a node in SiteB (NodeB), and wants to refer NodeB to the FooBar
> server in SiteA, what does it do?
I thought we agreed, completely outside of IPv6 concern
> Eliot Lear wrote:
> Right up till the point where two companies start communicating
> with one another directly with site-locals.
No, no, no. That's exactly what we don't want site-locals to do.
Site-locals are not to communicate outside their own site, period.
Michel.
On Mon, 31 Mar 2003 15:49:03 CST, Matt Crawford <[EMAIL PROTECTED]> said:
> > Let's assume that there is a FooBar server in SiteA. If another
> > node in SiteA (NodeA) is communicating via a multi-party application
> > to a node in SiteB (NodeB), and wants to refer NodeB to the FooBar
> > server
Margaret Wasserman wrote:
> I believe that you have misunderstood my point... I'll try
> to explain further, although our friends in the applications
> area may be able to give better examples.
>
> Let's assume that there is a FooBar server in SiteA. If
> another node in SiteA (NodeA) is comm
On Tue, 01 Apr 2003 00:23:15 +0200, Jeroen Massar said:
> Effectively this could be resolved by having one globally
> unique identifier per node. The underlying protocols should
Paging Noel Chiappa Paging Noel Chiappa ;)
pgp0.pgp
Description: PGP signature
Tony Hain wrote:
> Margaret Wasserman wrote:
> > I believe that you have misunderstood my point... I'll try
> > to explain further, although our friends in the applications
> > area may be able to give better examples.
> >
> > Let's assume that there is a FooBar server in SiteA. If
> > anoth
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] wrote:
>
> On Tue, 01 Apr 2003 00:23:15 +0200, Jeroen Massar said:
>
> > Effectively this could be resolved by having one globally
> > unique identifier per node. The underlying protocols should
>
> Paging Noel Chiappa Paging Noel Chiappa ;)
B
On Monday, March 31, 2003, at 05:30 PM, Tony Hain wrote:
Let's assume that there is a FooBar server in SiteA. If
another node in SiteA (NodeA) is communicating via a
multi-party application to a node in SiteB (NodeB), and wants
to refer NodeB to the FooBar server in SiteA, what does it do?
Send
Margaret,
> Margaret Wasserman wrote:
> (2) Institutionalizing the need for split DNS. I understand
> that some network administrators choose to use split DNS
> today, but that doesn't meant that we want to build a
> requirement for split DNS it into the IPv6 architecture.
I don't think "Institut
Margaret Wasserman wrote:
> Of course, in the case of site-local addresses, you don't
> know for sure that you reached the _correct_ peer, unless you
> know for sure that the node you want to reach is in your
> site.
Since the address block is ambiguous, routing will assure that if you
reach
Thus spake "Eliot Lear" <[EMAIL PROTECTED]>
> Right up till the point where two companies start communicating with
> one another directly with site-locals. Even if there is a router frob to
> keep the scopes scoped, you can bet it won't be used until someone
> realizes that the above problem occur
> From: Keith Moore <[EMAIL PROTECTED]>
> actually it's bad to force all apps to use DNS names - which are often
> less reliable, slower, less correct, and more ambiguous than IP
> addresses.
This is like saying it's bad to force people to use cars/busses/whatever
because they occ
> From: [EMAIL PROTECTED]
>> Effectively this could be resolved by having one globally
>> unique identifier per node.
> Paging Noel Chiappa Paging Noel Chiappa ;)
Ah, one moment, if I may:
"his books, he always said, contained the teachings of his master,
Socrates; .
% > > Let's assume that there is a FooBar server in SiteA. If
% > > another node in SiteA (NodeA) is communicating via a
% > > multi-party application to a node in SiteB (NodeB), and wants
% > > to refer NodeB to the FooBar server in SiteA, what does it do?
% >
% > Send a name.
%
% Not all ad
--On Monday, 31 March, 2003 09:01 -0800 Bill Manning
<[EMAIL PROTECTED]> wrote:
Is may be worth noting that RIRs have -NEVER- made
presumptionson routability of the delegations they make.
I believe that, although I remember some arguments within ARIN
back when I was on the AC about
Keith Moore wrote:
> > > Well, that is emphatically *NOT* what application developers
> > > do. They do not just observe that it does not work, they try
> > > to work around, e.g. routing messages to a different address,
> > > at a different time, through a third party, or through a
> > > differe
> > All right, how do you make internal site communications completely
> > oblivious to a change in your externally-visible routing prefix?
>
> You declare that any app that keeps connections around for more than
> some time period T (say for 30 days) have a mechanism for
> detecting and recoverin
Keith Moore [mailto:[EMAIL PROTECTED] wrote:
> > > > Indeed, correctly coded applications will use a getaddrinfo()
> > > > and then a connect() in a loop until succesful.
> > >
> > > it's perfectly reasonable to connect to an address without first
> > > doing a DNS lookup.
> >
> > I think nobod
% >But suppose we really do have enough address space (independent of routing
% >issues). In that context, is site local just a shortcut to avoid dealing
% >with a more general problem? Should we have a address allocation policy
% >that updates the policies of the 70s but ignores the intermedi
-BEGIN PGP SIGNED MESSAGE-
> "Bill" == Bill Manning <[EMAIL PROTECTED]> writes:
Bill> Are the apps for which IPv6 is enabled that -can not-
Bill> use address literals? If so, then Steve is wrong and
yes.
Both IPv4 and IPv6 web browsers behave differently if
1 - 100 of 120 matches
Mail list logo
