ure in the discussion on translating internet [sic]
addresses to local addresses starting towards the bottom of
page 5 of IEN 48?
Sean.
- --
Sean Doran <[EMAIL PROTECTED]>
Mike Padlipsky Fan Club
| 1. if IPv6 allocation policies aren't a fair amount more liberal
|than IPv4 ones in how much address space is doled out, they're
|broken. there's still a need to aggregate addresses for routing
|purposes, but there's no need to be stingy about doling them out.
We are agreed that t
Bill Manning <[EMAIL PROTECTED]> writes:
> % So, how many /20s are there in IPv6?
>
> The same as IPv4. Oh, you mean the number of prefixs that
> carry the same number of end-node addresses as an IPv4 /20?
> That would equate to the number of /116's in IPv6 parlance.
So how many /20s or how ma
Christian -
| Sean, the appropriate answer to your question is RTFM (as in, read the
| manual.) The top 48 bits of IPv6 addresses are anything but flat. The flat
| space is initially limited to the top 16 bits, 3 of which are used as a
| format prefix, leaving a "flat space" table size of 8K entr
| This is the plan. We start out with no holes in BGP and we try to
| keep it that way.
Ah, BGP.
Ok, so it seems like there is a 1-1 mapping of TLAs to AS numbers --
after all, why would an AS encompass more than one TLA prefix?
What happens if and when the 8k limit on TLAs is relaxed, because
| so i had a nearby scheme interpreter
yay. (now go fix all the buggy scheme and lisp packages in -current :) :) :) )
| It seems obvious to me that the only way routing can scale with
| addresses this large is with very aggressive aggregation.
It would work better still with abstraction, henc
| > It's possible that some multihomed sites will have to assign 4 or even
| > more ip addresses per host, depend on what kind of ISPs they multihoming
| > with. E.g. a site that happen to multihome to two tier-2 ISPs, each
| > multihomed with two different tier-1 ISPs, each host in this multi
| given TCP's inability to do congestion-sensitive backoff during
| connection establishment, I'm not so sure that increasing the number
| of concurrent connection attempts is a good idea.
I am pretty sure it is NOT a good idea.
| the selection of the server with the ... lowest [RTT]
| was ofte
Dan Grossman writes:
| ATM has a carefully defined traffic management architecture.
Yes, that's its problem.
>From issue 10 of "New Carrier" (http://www.totaltele.com/newcarrier", p 22:
... the past several years' debates over the relative technical
merits of [the] Internet Protocol versus
[Keith Moore on a "KMart box"]
| take it home, plug it in to your phone line or whatever, and get
| instant internet for all of the computers in your home.
| (almost just like NATs today except that you get static IP addresses).
No, not "or whatever" but "AND whatever".
Otherwise this is a ni
| it's not at all clear to me why households need traditional multihoming,
| nor how to make it feasible for households to have it. so I would regard
| this as overdesign of the home 'internet interface box'
Three observations:
1.
In the past, when and if large arrogant backb
Dick St.Peters writes:
| I should probably just go back to lurking
No, these are fundamentally hard problems, and nobody has real answers.
What is interesting is that people haven't asked real questions either,
and yet have decided that the correct approach is IPv6.
| but ... my take on every
|
Ohta-san:
| > No, not "or whatever" but "AND whatever".
|
| Do you mean "plug THEM in to your phone line and whatever"?
Yes, that is certainly one possibility. I imagine the "inside"
interface would be some easy-to-wire LAN interface, enabling THEM
to communicate using whatever protocol/addres
asp writes:
| Or seperate the end system identifer from the routing goop. This
| solves lots of problems (while introducing others).
Right, so in the 8+8 model, some router performs a NAT function by
writing in the routing goop portion at an address abstraction boundary.
The host does not need
Steve Deering writes:
| Sheesh -- we get flamed for trying to impose a limit on the number of TLAs
| and we get flamed for the possibility that the number TLAs might not be
| limited...
The salient point here is that the current inter-domain routing
architecture is not robust to growth in the n
Thomas Narten writes:
| I don't know about you, but it scares me to read the various forecasts
| about how wireless will transform the landscape over the next few
| years.
It scares me how much people buy into hype.
I seem to recall reading forecasts about many bright shiny trendy
things would
Thomas Narten writes:
| The point of the IPv6 addressing architecture is to make that
| sort of multihoming a _possibility_ and an _optimization_ rather
| than a _requirement_.
In a purely technical sense, redundancy of any sort is
an _optimization_ rather than a _requirement_. There
is absolu
Thomas Narten writes:
| Actually, if your assumption is that NATv6 is better than IPv6 with
| renumbering, then IPv4 and NATv4 was good enough to start with and
| there was need to move to IPv6 in the first place.
^
no (right? maybe this is where the previous "not" came fr
Keith Moore writes:
| the core will support v6 when it makes economic sense - i.e. when
| top tier ISPs can save enough on bandwidth and support costs (as compared
| to tunneling) to make the investment worthwhile.
Perry Metzger had this to say a long time ago (1999 12 03):
>Peter made the abs
Bill Manning <[EMAIL PROTECTED]> writes:
> There is near zero value in the number/address and
> very real value in the routing slot. Perhaps it is best
> to simply have ebone route filter on the /16 boundaries
> to drive home your point. (being cranky this morning)
Bill -
I utterly reject your
Ohta-san:
|
While I agree with you that the current usage-based allocation
system is wrong, your draft's "Assignment Plan" (not more restricted)
proposes to continue an anti-market single-seller model for IP
addresses of both IPv4 and IPv6 flavours. There is no scope
for negotiating wit
Randy Bush writes:
| actually it might be a feature to torture the anti-nat bigots
Maybe they wouldn't notice.
Sean.
Keith Moore writes:
| > Sprint PCS uses a NAT,
|
| wish I had known that before I bought one of their phones.
| criminals.
Keith, you need a major attitude readjustment.
Sean. (who notes you didn't even NOTICE the NAT, if there is one)
Brian Carpenter writes to Anthony Atkielski:
| > The telephone company figured out how to avoid problems decades ago. Why
| > the computer industry has to rediscover things the hard way mystifies me.
|
| The telephone company has milliseconds to seconds to resolve an address
| into a route. The
John Kristoff <[EMAIL PROTECTED]> writes:
| To do nothing can be far more dangerous (as proven by the disdain for NAT).
The disdain for NAT is non-uniform. Personally, I rather like NAT.
| Can IPv6 be worse for the net than NAT?
IPv6 and IPv4 will coexist for a time; the topology of the (la
Fred Baker asks:
| When I build a telephone out of an IP dialler attached to
| someone's waist, a modulator on their necklace, and an earphone attached to
| their earring, all connected by IP on BlueTooth, what addresses do I put on
| the different components of the telephone?
RFC-1918 for a
| good god we have the lobbyists trying to engineer the Internet
| now - everyone is an expert it seems. :-(
Thank heaven for the IPv6 "B Ark" that distracts such people
from real engineering issues.
Sean.
Fuel for the B Ark...
Brian Carpenter writes:
| Sorry, this makes no sense at all. There is no way to "restrict"
| certain types of domain name that has any meaningful effect
Eh? I can assure you that my colleagues and I will defend the
brand value of, for example, ebone.net, by only delegatin
Mike Trutkowski writes:
| Maybe I read this wrong... but it sounds like you are
| tieing a domain name to domain content? Is this true?
No, I am tying a domain's acceptable use policy to the
registered owner of the domain. One possible AUP requires
that any data associated with any of its su
I wrote:
| Consider the IPv6 [SELECT] draft -- if you have an algorithm in
| your host which allows only "kid-safe" connections (e.g., if you get
| back several RRs, discard any that are not "kid-safe") -- then
| you can connect to the "www.disney.com" servers (and they to you),
| but not t
Andy -
| This could be done in the case of Country/region code TLDs under the
| control of the individual registries. It couldn't be done fairly the case
| of the 'international' TLDs such as .COM .NET and .ORG or any new
| non-country/region specific names because no two countries would agree
| Of course you would. You work for a provider and can get all the
| address space you want.
Oh, Perry. Your ignorance is showing.
Sean.
Thomas Narten writes:
| So, once again, it appears
| necessary to point out that approaches that work fine in IPv4 work
| just as well in IPv6. But IPv6 also enables new approaches as well,
| some of which are not really practical in IPv4.
You and I are in perfect agreement, though -- I simply p
"Anthony Atkielski" <[EMAIL PROTECTED]> writes:
> It isn't really that clever. For one thing, the
> standards for any given category of addresses will vary
> from one community to another,
Ah, no - the clever thing is partitioning the address
space at all. Whether or not this particular partit
Keith -
| it's not practical in IPv6 either.
What isn't? Partitioning at all, or using this particular partition?
Sean.
Keith -
| a one-bit content label is even harder to use than the PICS stuff.
|
| all of the objections about this being improper use of the address
| space also apply, but even if those were overcome, the scheme still
| wouldn't solve any problems. it would accomplish nothing except to
| waste h
Brian Carpenter writes -
| Please, please, nobody ever pick a prefix at random.
Why not? The chances of collision are quite small. Moreover, in
the event of collision, IPv6 is supposed by design to facilitate
automatic renumbering, so moving to another prefix should be easy, right?
That's the
Itojun -
| First of all, do not cook up IPv6 prefix on your own. You cannot pick
| random prefix number, that can jeopadize the whole point of experiment.
Could you expand on that please? So far, I see from Matt Crawford a single
reason (IP6.INT coordination), and that at least should be in th
Itojun -
>o The site may use the address prefix: 3ffe:0501:::/48. The address
> prefix was curved out from WIDE 6bone prefix. The site MUST be
> renumbered, before the site gets connected to the worldwide IPv6
> network.
Shouldn't IPv6's much-trumpeted stateless autoconfiguration and
re
ir attitudes
were changed, some useful engagement may happen.
Otherwise, Metzger's deployment scenario below is probably
the only realistic one, because no business in its right
mind would want to support a collection of people whose
leaders openly accuse them of everything short of baby-killi
At the risk of having an Internet AD accuse me of SPAMming or trolling...
"David R. Conrad" <[EMAIL PROTECTED]> writes:
> As Brian said, get address space from your upstream
> provider. If your provider doesn't support v6, find
> another. If you can't find another then get used to and
> deal
Matt Crawford writes:
| Sean, you knowingly and deliberately wasted people's time all week
| with your nonsensical suggestions (as evidenced by your first
| message's label "Fuel for the B Ark") ... and you now want us to
| believe that you're upset by being told that you're wasting our time?
I'
Hakikur Rahman <[EMAIL PROTECTED]> writes:
> I agree with Brian Carpenter,
> "We expect millions of those during v6/v4 coexistence."
> Hakik.
So back to my original question, which apparently none of
the IPv6-Leaders liked:
-- if we are doing tunnels which follow a logical
topology rathe
Robert Elz <[EMAIL PROTECTED]> writes:
> There's nothing different this time, the established
> IPv4 network providers see something that is challenging
> their established way or operating
Funny, that's EXACTLY what an ATM fan said to me in 1995!
Sean.
"David R. Conrad" <[EMAIL PROTECTED]> writes:
> Only transit providers (whatever they are) should be getting v6
> addresses from the registries.
Since deployment seems to be based initially upon virtual
topologies that are disjoint from the underlying IPv4
topology (i.e., using tunnels), surely
is there an IETF policy wrt spamming people with information gleaned
from the blue sheets passed around in WG meetings?
that is, if I am spammed to a blue-sheet-address, is there any
point in whining about it, other than to feel morally superior
to the spammers?
Sean.
Hi -
Is it appropriate to name & shame people who were cutting into
line yesterday during the social event, yet who did not admit to
and fix the error of their ways when it was pointed out that this
unfair behaviour is inappropriate?
Those few of you who shrugged off a polite suggestion to
Thanks for the feedback, public and private.
It is pretty clear that we attendees should talk to
Qualcomm and Cisco about the disorganization of the social
event. Our individual account team or sales people seem
like good targets for complaints.
However, wrt queue-jumping, there is a serious q
Hi -
I should have waited until Perry had spoken, because now that he has
pointed out the extreme cost of NAT, I have seen the light!
NATs are expensive. They have gross side-effects. Even Noel Chiappa,
my guru, says that they are an architectural hack.
So, why are people deploying them?
Th
| It's already happening. Try running IPSec from one 10 network to another 10
| network. Much pain.
Surely the "much pain" is because, as Melinda Shore indicates,
some "anti-NAT fanatics" cannot understand the distinction
between "who" and "where"?
NAT merely exposes and exacerbates the p
Perry Metzger writes:
| Maybe because I hear from folks like you and others that you're
| ideologically opposed to deploying v6 instead of against it for
| technical reasons?
You have never heard this from me.
I have no doubt whatsoever that you have heard this from others
speaking about me. T
of *me* that IPv6 isn't a stunning success compared to NAT?
I didn't realize that, when I asked the IAB to use their technical insights
as a market predictor, that behind the invisible hand of the marketplace
lurks little ol' me. Maybe someone should tell Paul Krugman.
Sean
Jon Crowcroft writes:
| anyhow, i think the old 8+8 v6 scheme would have sorted this out just
| dandilyand i dont understand the vitriol people our on it -
I don't understand alot of the vitriol, but I personally am concerned
that 8 bytes is insufficient. If there was ever a time-space trad
Keith Moore writes:
| if you try to build a global network out of limited-scope addresses
| you eventually end up reinventing IP at a higher layer.
Correct, that's (some of) the point of CATNIP (RFC 1707): you construct
a network layer out of a virtual superset of the component internets'
addres
Keith Moore writes:
| but I'm fairly convinced that we are *far* better off with a global
| name space for network attachment points, which are exposed and
| visible to hosts and applications, than we are with only locally
| scoped addresses visible to hosts and applications
Out of curiosity, do
Steve Bellovin, on IPSEC, not-AH:
| [A] host's identity is represented by its certificate (I'm speaking a bit
| loosely here); its IP address is merely the way that packets reach it.
This is an example of two separate namespaces that allow one
to distinguish between "who" and "where". That
Ran Atkinson writes:
| The semantics of an FQDN is not crisp and clear
| these days as is once was.
Wow, your memory must be better than mine if you remember
crispness & clarity. :-)
| For example, www.cnn.com names a set of content
| rather than naming a single given host.
| from label switching, so what I'm suggesting is that we take the bull by
| the horns once and for all and run MPLS over IP instead of under it...
an mplsd-like tag fits neatly in the first half of an ipvsux destination
address, although there are other places in the vsux header you can put
t
Keith Moore writes:
| yeah, I really wish those who are trying to improve network routing
| (an endeavor which I respect in principle) would consider that
| applications really do need stable endpoint identifiers which
| are globally scoped, exchangable with other applications, and
| reliably u
This is an interesting article to read.
Some highlights:
"[Websites can block users] by employing the same
technology that serves up tailored banner advertisements
to visitors from another country. They track the
Internet service provider's "IP address", the number
that identifies co
| Sean, re the IPv6 myth propagated in this article, see
| http://playground.sun.com/ipng/specs/ipv6-address-privacy.html
Yes, this solves the lower-8-bytes in a notional 8+8, in the
sense that it is an identifier of "who", but the draft in question
does not seem to deal with the nature of the "
Keith Moore writes:
| at least in those days, gateway proponents didn't insist that people
| shouldn't include email addresses in the bodies of their messages.
You miss the point that including "GRECO::MARYK" as an email address
in a USENET message is about as useful as including 10.0.0.26 in an
Valdis Kletnieks writes:
| On Mon, 22 Jan 2001 23:53:30 +0100, Sean Doran said:
| > Nobody really constrains protocols from carrying a local IP address
| > around any more than anyone constrains from putting local addresses
| > into a text message. It's just that communicat
| Nowadays people often act as if NATs were the way the Internet was supposed
| to work, and that it's the applications and the users of those applications
| who are broken if they want a network that supports a global address space.
Well, the genie is out of the bottle, and if NAT is winning
| I hear that people aren't passing prefixes longer than /20. Is this
| true, and how broadly is this being implemented? If I wanted to advertise
| my own IP space (say a /24) instead of space provided by my ISP, would many
| ISP's not pass my route because of prefix length?
I am sure th
Randy Bush writes:
| how well do you think this scales? if the isp(s) you are asking think of
| it as what could be the first of a few thousand such requests, do you think
| 'small' payment might be a bit optimistic?
Well, you could bribe Curtis to drop some PRDB software on you and...
Bill Manning writes:
| and tosses it w/o any abilitiy to notify the originating
| party.
Why is it necessary that there be an inability to notify the
originating party? dkerr already proved it's cheep cheep cheep
to maintain some types of state even with lots of flows per second,
and the
N.B.: I trimmed this:
| From: Keith Moore <[EMAIL PROTECTED]>
| To: "Melinda Shore" <[EMAIL PROTECTED]>
| Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
| [EMAIL PROTECTED]
| Subject: Re: Mail sent to midcom (fwd)
| Sender: [EMAIL PROTECTED]
Down to this: [EMAIL PROTECTED]
| I don't see why this generates comments about anti-NAT religion.
I prepared a shockingly rude but very funny riposte to this message,
however the spirits intervened and decided to make a poorly-aimed
wheel-mouse motion kill the editor in a surprising way.
Unless this can be attributed to the
| I respectfully but firmly disagree that this is "the discussion at
| hand", or even that such a discussion is a useful. but if you must
| have that discussion, please take it to the midcom list.
Ah, sorry, mea maxima culpa - I had misread (several times)
the To:/Cc: line as containing the mi
I realize that this is more of an operator's nightmare than anything else,
but nevertheless, some of you may be interested in this article:
http://www.business20.com/content/channels/technology/2001/03/02/27329
I wonder if the future's most effective denial-of-service attacks
will simply trigger
Brad Hunting writes:
| It even uses fewer resources for network providers.
|
| "The real difficulty of multicast" is that it's much more difficult
| for ISP's (and presumably router venders) to support than unicast.
These two statements are, unfortunately, mutually exclusive.
IP multicast does
| Well, what about scalability, and the interoperability with the underlying unicast
| protocols. and what about the interdomain multicast???
IDR for multicast is pretty straightforward:
1. discovering sources: SA handling done by MSDP works OK, there
are maybe better ways of
Ohta-san:
| Because best effort service is flat rated, receivers are not motivated
| to use multicast. Senders learned to have more servers.
Yes, but some senders would like to send a bit less :-)
For instance, some are actually paying based on volume (Mbytes/month),
some are paying on peak usa
Perry -
| the folks deploying v6 are doing something
| about the problem -- they've got running code and running networks and
| running applications -- and you're bitching in the hotel bar at the IETF.
No, I don't think he is. In fact, you would be hard pressed
to find Noel showing up at an I
Geoff Huston writes:
| If you look away from an address -based hierarchy and define other objects
| as the 'atoms' of a routing system then there may be some benefit. Even
| today, with some 105,000 objects in the routing table (*) there are only
| some 12,000 AS's (*) and 15,500 AS paths sele
Perry Metzger writes:
| You seem to dismiss link state offhand, but it
| isn't clear that link state couldn't help out a lot here. (Neither is
| it clear that it could but it appears to be an interesting area for
| some experiments.)
Actually, I'm a fan of link state (ask Sue Hares or Dave Ward
Peter Ford writes:
| It must change: "eventually". For short duration changes you have
| Mobile IP. For changes that have longer time horizon you have host
| renumbering, which by the design of v6 is now fairly trivial. Seems
| like this base might be adequately covered, no?=20
I would love
Perry Metzger writes:
| Ah, but then what's your method for mapping between the two, and how
| fast must *it* run and how well does *it* scale?
...
| I'm not saying such a thing doesn't exist. I'm just saying that I
| haven't seen a worked example I can believe in.
Stay tuned to multi6.
We
| Who says you need to use the IP addresses for that purpose? There is
| plenty of precedent -- for a a long time we've had this notion of the
| routing protocols adding labels on that had nothing to do per se with
| the IP address. See the "AS" notion, for example, in which we label
| various cl
| However, to come up with an architecture which has separate concepts of
| identity and location, there can't be any direct relationship between them
| at all (other than mapping through some kind of database).
Well, it's sufficient to have the identity not be dependent upon the
location. Th
Erik Nordmark writes:
| > A locator by definition must describe a precise location within
| > a network, such that any router will be able to forward traffic
| > towards that network using only the information in locator.
|
| Towards the network/link or towards the node?
Sorry, imprecise wordin
Peter Ford post ROAD writes:
| I concur that the routing guys have some work in front of them. May I
| suggest people take a closer look at hierarchical routing, combined
| provider and geographic hierarchies, and adult supervision?
All of these have been well-studied with IPv4.
Unfortunately
| at present our locators are AS numbers.
No, Keith, they are not.
The AS number does not describe a location in any sort of topology.
It is simply a representation of a set of routers with the same
routing policy, that should not receive via eBGP NLRI which
have originated from or passed throu
Keith Moore writes:
| there is another important difference between v4 and v6 - we don't have
| enough addresses for everyone to use v4.
(... at the same time)
That is, either some subset of everyone can use v4 with addresses
which are changed relativ
Harald -
Thanks for the short memorial this evening; those of us who would
have been sitting with her during the plenary would not have been able
to take anything much longer.
FYI, there is a fine memorial and collection of pictures
available at http://www.nanog.org/abha.html
She would have th
Ran Atkinson writes:
| - Reception & Social might be merged together on Sunday evening.
The trend in vendor-sponsored social events lately has been so
abysmally awful that even working group meetings are less tedious,
so I fully support this suggestion for getting the Tuesday night
event
87 matches
Mail list logo
