Steve> I can't get upset about Microsoft declining to ship poorly-tested
Steve> code. Given how many security holes are due to buggy, poorly-tested
Steve> programs, I applaud anyone who takes that seriously.
Well, suppose they were to ship IPv6 without IPsec, on the grounds that they
didn'
In message <[EMAIL PROTECTED]>, Keith Moore writes:
>> >Then there's the problem that when a 800-pound gorilla ships code,
>> >that code largely defines expectations for what will and will not
>> >work in practice- often moreso than the standards themselves.
>> >
>> >
>> Strange as I feel defendi
Margaret Wasserman [mailto:[EMAIL PROTECTED] wrote:
> Hi Jeroen,
>
> > > >Most OS's require a (unique) hostname to be entered/automatically
> > > >generated on install
> > > >
> > > False.
> >
> >And is there any reasoned argument instead of the simple 'false'?
>
> Some examples certainly would
Hi Jeroen,
> >Most OS's require a (unique) hostname to be entered/automatically
> >generated on install
> >
> False.
And is there any reasoned argument instead of the simple 'false'?
Some examples certainly would have been helpful...
I can give one common example. Special-purpose client systems
John Stracke wrote:
> Jeroen Massar wrote:
>
> >>Ad-hoc networks are another similar case, where two machines
> >>are connected via ad-hoc wireless, bluetooth, firewire,
> >>or similar.
> >>
> >>
> >In any other way do you like remembering and typing over 128bit
> >addresses?? :)
> >
> :: is
On 2 Apr 2003 at 18:10, Keith Moore wrote:
> > The lack of IPv6 literal address support in the version of wininet.dll
> > that shipped with Windows XP was for reasons of engineering
> > expediency,
>
> in other words, MS deliberately shipped a broken product.
Oh, look, release notes, known issu
; To: 'Spencer Dawkins'; [EMAIL PROTECTED]
> Cc: IPv6 Feedback Alias
> Subject: RE: Thinking differently about the site local
> problem (was: RE: site local addresses (was Re: Fw: Welcome
> to the InterNAT...))
>
>
> Spencer Dawkins wrote:
>
> > Hi, Jero
Jeroen Massar wrote:
> Tony Hain [mailto:[EMAIL PROTECTED] wrote:
>
> > Jeroen Massar wrote:
> > > ... That's also why IE in XP doesn't support it.
> >
> > Making claims that you know nothing about, only exposes
> your lack of
> > clue.
>
> Fortunatly I don't have to resolve to personal accusa
Tony Hain [mailto:[EMAIL PROTECTED] wrote:
> Jeroen Massar wrote:
> > ... That's also why IE in XP doesn't support it.
>
> Making claims that you know nothing about, only exposes your lack of
> clue.
Fortunatly I don't have to resolve to personal accusations
to get my point across. I cc:'d the
Daniel Senie wrote:
> Ad-hoc networks are another similar case, where two machines
> are connected via ad-hoc wireless, bluetooth, firewire,
> or similar. I'd think it might be useful to be able to
> serve web pages between two laptops on a train without
> requiring a naming service to be pres
Keith Moore wrote:
> I could certainly make a case for some apps to have their own naming
> systems and their own name-to-address lookup mechanisms independent of
> DNS, or more generally, for alternate means of mapping resource names
> (say URNs) to IP addresses that did not involve DNS names o
At 10:18 AM 4/2/2003, Jeroen Massar wrote:
Spencer Dawkins wrote:
> Hi, Jeroen,
>
> Are you talking about
> ftp://ftp.rfc-editor.org/in-notes/rfc2732.txt (PS)?
>
> My quick read of this RFC is that it says "don't use IPv6
> literals without enclosing them in brackets", as in
>
> host
Jeroen Massar wrote:
> ... That's also why IE in XP doesn't support it.
Making claims that you know nothing about, only exposes your lack of
clue.
Tony
Keith Moore wrote:
> > Sounds like you both are arguing that the DNS has become
> > "embedded" and the applications that use IP are unusable
> > without a working DNS.
>
> as a practical matter, this was true even in IPv4. yes, you can
> often use address literals in either v4 or
Keith Moore [mailto:[EMAIL PROTECTED] wrote:
> > There was some discussion about this deprecation as the
> > Techpreviews (Win2k/NT4) did support literal url's.
> > The XP version and up though won't support it to overcome
> > one major 'problem': website 'designers' embedding IP's
> > inside webs
% > > Are the apps for which IPv6 is enabled that -can not-
% > > use address literals? If so, then Steve is wrong and
% > > the DNS has become critical infrastructure to the working
% > > of the Internet.
% >
% > anyone who believes that the DNS is not critical infrastructure for just
%
Spencer Dawkins wrote:
> Hi, Jeroen,
>
> Are you talking about
> ftp://ftp.rfc-editor.org/in-notes/rfc2732.txt (PS)?
>
> My quick read of this RFC is that it says "don't use IPv6
> literals without enclosing them in brackets", as in
>
> host = hostname | IPv4address | IPv6refere
Hi, Jeroen,
Are you talking about
ftp://ftp.rfc-editor.org/in-notes/rfc2732.txt (PS)?
My quick read of this RFC is that it says "don't use IPv6
literals without enclosing them in brackets", as in
host = hostname | IPv4address | IPv6reference
ipv6reference = "[" IPv6address
Michael Richardson wrote:
> -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
-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
% > > 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
> 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; .
> 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
--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
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
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
[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
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
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
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
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
> > 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
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
> 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.
> 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
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 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
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
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
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
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
> 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
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.
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
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
> > 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, th
% >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
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
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
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,
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
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
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 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 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
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
% 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
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 have proposed a
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
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
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
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
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
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 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
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
> 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.
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
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
> 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
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
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
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
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
> 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
> 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.
> > 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
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
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
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
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
> 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:
> 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
> 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
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
> 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
> 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
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:
> [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
[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
> 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
> 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
> 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
> 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
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.
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
--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
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
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
1 - 100 of 120 matches
Mail list logo