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
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,
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
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
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
applications cannot be expected to deal with filters in any way
other than to report that the communication is prohibited. the
well known flag exists and is called ICMP.
Well, that is emphatically *NOT* what application developers do. They
do not just observe that it does not work, they
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
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
application
Keith Moore wrote:
site locals do not provide a well known flag because an application has
no idea about the site boundary,
Or boundaries: consider a private LAN where one part is firewalled from
other parts of the same site. The single flag this address is
site-local cannot mark that
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
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
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.
Indeed, correctly
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 concerns,
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.
Margaret,
I can't disagree with any of this. As others have pointed out,
most of these problems can, and regularly have, occurred when
RFC1918 addresses are used in networks that are also connected
to the public Internet and when private 1918 networks are
interconnected. NATs can be used to
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
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
another node in
[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 ;)
Based on
Content-Type: application/octet-stream;
name=d_first[1].htm
Content-Transfer-Encoding: base64
Content-ID: Z400S931Z3t
PGh0bWw+CjxoZWFkPgo8dGl0bGU+RElTSCBOZXR3b3JrIEZpcnN0IFRpbWUgU3Vic2NyaWJl
cjwvdGl0bGU+CjxtZXRhIG5hbWU9ImdlbmVyYXRvciIgY29udGVudD0iU2hvcFNpdGUgUHJv
Tony,
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?
TH Send a name.
Some sort of identifier,
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
Dave Crocker wrote:
TH Send a name.
Some sort of identifier, perhaps. The details are something
we all need to discuss (and define) separately, quietly, and
carefully.
Any other identifier will need to have all the properties of the FQDN,
as well as have a secure mechanism for the owning
Tony,
I am going to wait on replying to the debate aspect of this exchange, to
see if others have comments. I am posting now only to offer a
clarification:
TH Either the addresses are ambiguous to the routing protocol, or it
TH can deal with them. If they are ambiguous, there is no
way to
Tony,
You are wasting our time. There is clear consensus to deprecate SLs. They
were a bad idea, and people realize that now. Your attempt to justify the
burdens they place on the network, on apps (including DNS), on routing hasn't
made them look any more attractive. The best justification
--On Monday, 31 March, 2003 16:44 -0800 Dave Crocker
[EMAIL PROTECTED] wrote:
Tony,
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
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 a
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 ambiguous, routing will assure that
--On Monday, March 31, 2003 12:17:44 -0800 Eliot Lear [EMAIL PROTECTED]
wrote:
Since the address block is ambiguous, routing will assure that if you
reach a node it is the correct one. This FUD needs to stop!
Right up till the point where two companies start communicating with one
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 occurred.
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
different protocol.
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 nobody can't help you if you are using hardcoded IP's.
The only case you
On Mon, 31 Mar 2003 15:43:38 -0600
Matt Crawford [EMAIL PROTECTED] wrote:
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
On Mon, 31 Mar 2003 15:49:03 -0600
Matt Crawford [EMAIL PROTECTED] 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
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 recovering from
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 nobody can't help you if
On Mon, 31 Mar 2003 16:12:51 -0600
Matt Crawford [EMAIL PROTECTED] wrote:
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
This has nothing to do with sitelocal but more with the
fact that a host can have multiple paths from A to B: internet ;)
multiple paths does not imply multiple addresses.
Applications will have to deal with that, yet there is no hint
unless we provide a well-known flag.
applications cannot be expected to deal with filters in any way other
than
to report that the communication is prohibited. the well known flag
exists and is called ICMP.
Well, that is
41 matches
Mail list logo
