On Sep 18, 2009, at 10:42 AM, Marshall Eubanks wrote:
We are therefore asking for input from the community by two means - by
commenting on the IETF discussion list, ...
I'm trying to imagine the thought police remaining calm during a
plenary such as the one at Danvers. I can't quite picture i
> > 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
> 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
> 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
> 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.
> 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
> 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
> > Not quite inherent -- if you verify against a SubjectAltName dNSName
> > you can decide the certificate is valid for many domains.
> >
> Yes, this is true in theory, but I want to know how you're going
> to get VeriSign to issue you a certificate with subjectAltNames
> corresponding to a bunch
> > Not clear. SMTP can relay a single copy of a message to multiple
> > recipients at multiple domains. Your suggestion would force a
> > separate TLS session, or a separate SMTP session, for every distinct
> > recipient domain.
>
> Yes, that's true, but that's inherent in the "one certificate"
> > There's no reason a protocol can't be spec'd to let the client convey
> > the name of the resource before the TLS handshake begins.
>
> no, there isn't. but it still wouldn't give the client a way to verify
> that the server is authoritative for that domain.
If it isn't, your trust in the C
> I see your point. But I suspect it illustrates a significant
> limitation of the SSL/TLS protocol - in that SSL/TLS seems to assume
> that an IP address and port number are used by only one named service.
> It's been awhile since I looked at the TLS protocol but I don't recall
> any way for
> > draft-ietf-dnsext-axfr-clarify-00.txt Nominum Inc.
> > March 2000
> > Seems to be 3 years ago.
> I remember when people thought OSI protocols took too long to
> standardize... :-)
"$X is a slow-moving parody of itself." -
eously,
My friend Dr. Einstein would like a word with you about your casual
misuse of the word "simultaneously."
__
Matt Crawford [EMAIL PROTECTED]Fermilab
> > An interesting subject for a thesis:
> >
> > The Porn and The Internet.
>
> Sub-titled The Beauties and The Beasts ?
Watch it. One fuzzball joke and I am outta here.
> Does anybody have a reference on an authorization scheme that
> doesn't imply any authentication?
"You will deliver the satchel to the one who presents the matching
half of this hundred-euro note."
> However, this raises a question: does *anyone* use external-body in
> association with I-D announcements?
I access new I-Ds and RFCs through the message/external-body subparts
of the announcement, and I sometimes send out documents of my own
(not always IETF-related) using the same mecahnism.
I
> Just how "fully worked" was IPv6 when the IETF picked it?
I clearly remember ipng area directors barging into wg after wg
exhorting them to ship whatever they had done, and never mind
the rest. "We can always fix it when we go to draft" was the
rationalization of the complaisant
> > > No. You can trace back to the fact that the signed data was at the same
> > ^
> > a hash of
> > > place as the private key, at the same time.
> > I've seen people *who operate CAs* lose sight of the fact that it's
> > The question of a global PKI is to remove anonymity. You can trace back
> > to a real person (legal person) from the certificate. Who can offer
>
> No. You can trace back to the fact that the signed data was at the same
^
> Barring that, please name ONE switch, or cite ONE credible reference
> source, where arpspoofing is prevented at the switch by any means short
> of harcoding the MACs.
Never mind, even hard-coding the MACs to the right ports doesn't
solve the problem. Eve on port X can keep up a steady stream
> On Sat, 20 Jul 2002 10:41:02 +0900, Jun-ichiro itojun Hagino <[EMAIL PROTECTED]>
>said:
> > therefore, it is unsafe to transmit ARP_REQUEST with spoofed IP
> > source address - it will overwrite ARP entries of neighbors.
(He meant sender address, of course)
Valdis Kletnieks said:
> Th
> Since the most frequent SSID is "pulver.com", I interpret this as
> the knife dripping with blood (but then Jeff could still be
> innocent even if the knife is engraved with his DNS name :-).
You mean, it could be a case of media-layer FRAMING?
> The IETF 54 broadcast information and the archive of broadcast sessions
> (none yet) is up now at the following location:
>
> http://videolab.uoregon.edu/events/ietf/ietf54.html
Wow, I can't remember the last time I got a *network* unreachable.
128.223.0.0 has fallen out of the routing system
> and RFC791 claims ttl is in seconds, ergo I don't have to decrement
> ttl because I know my traffic is on paths less than a second
> long.
>
> Cool reasoning.
You lose -- 791 says you have to subtract at least 1 from TTL even if.
However, I think that (A) most or all extant IPv4 routers viola
> however, it may be useful for folks to actually read the draft
> before making comments... thus far, i've only seen two folks with
> comments who claim to have actually read the thing.
OK, here's a new data point: I read it all and I have no comment. It
is neither more nor less than it purpor
> > > essentially all of the work done at meetings happens in the hallways,
> > > restaurants, and bars - when small groups of people get together ...
> >
> > Yes, I see. So much for the myth of an open process.
>
> I'm willing to place bets that a *very* large chunk of things
> accomplished in
> essentially all of the work done at meetings happens in the hallways,
> restaurants, and bars - when small groups of people get together ...
Yes, I see. So much for the myth of an open process.
Don't feed the troll. If he'll believe that gravity is an illusion
caused by neutrinos pushing in from space
( http://amoureternal.com/oti/gravity/page1.htm )
he'll believe anything. Anything, that is, except the voice of
reason. Which as *we* all know, is seldom found OnTheInterNet.
(Just
> In what layer is PPP in the TCP/IP=
> =20suite?
Layer 2.71828
> I think two plenary's is a good idea.
>
> If we seriously used the time on friday, thus making thursday
> night more legitmate to schedule staying in town, that would help.
> also would mitigate the horrible double booking of wg meetings
I think devoting Thursday night to a plenary is one fact
> IEEE 802.11 / 802.15 meetings have solved this by attaching a helium
> ballon to their equivalent of the blue sheets. That way everyone can
> see where they are and if they have gotten hung up.
That's a fun solution to the more general problem of slow blue-sheet
propagation. For the name harv
> It seems to me that these two can't both be true. IP Addresses cannot at
> once be scarce enough to charge for and non-scarce enough that scarcity is
> a non-issue.
>
> Does anyone else see something schizoid about this discussion?
Not I. I, as an end user or small site, cannot use just any IP
> However, the fact that a customer doesn't behave according to the ISP's
> assumptions does not inherently mean that the customer is stealing service -
> unless the customer has contractually agreed to limit the use of his
> internet service.
Have you looked at any of these ISP's contracts? Jus
> do away with pre-formatted pagination. rely on section numbers for
> references.
Then you would keep tables and ascii-art diagrams from
being split ... how?
> From http://www.ietf.org/meetings/0mtg-sites.txt:
> Spring 2002 - 53rd IETF
> March 17-22, 2002
> Location: Minneapolis, MN
>Host: TBD
We could have wished for nicer weather, but everything else went
pretty well there.
> > > Not just a lock, but there's a bridge to worry about; passing under it
> > > at low tide is your height limit.
> >
> > i would imagine the problem would be at high, not low, tide.
>
> oops. mea culpa.
Not at all. On a trip between oceans, waiting less than 12 hours for
a favorable tide i
Please suggest me place or a Document where i can get some information about
" Carrier Class Gateway".
There is no such thing. Neither the Panama Canal, the Suez Canal,
nor any other man-made waterway has locks large enough to accommodate
a modern aircraft carrier.
> Open standards is a fine thing, but you have to have some implementations
> and common use before it really matters. And let's not forget what the
> goal was: allow people to remotely participate (for some value of
> "participate").
Cool! Where can I get this free two-way interactive RealAudio
> Let's see, the price is right, the convention center has plenty of room,
> there are loads of hotel rooms nearby. Hmm. Sounds great!
>
> >OK, I'll bite:
> >
> >Kuala Lumpur which we just used for APRICOT 2001. Five-star hotel, the Pan
> >Pacific $63 per night.
Let's see, with the higher airfa
> > As long as about 2/3 of the IETF attendees are from North
> > America, 2/3 of the meetings should be in North America.
>
> similar logic might apply to havana.
>
> or, as long as 2/3 of the meetings are held in north america,
> 2/3 of the attendees will be from north america.
You're being s
> > I want to give you the benefit of the doubt. So, a gentle reminder. There
> > are women out here too.
>
> He doesn't appear to be a native English speaker; I doubt that he
> meant to exclude women. He probably meant "people" or "folks"
> rather than "men."
>
> I expect he speaks English
> > Title : Generalized Multi-Protocol Label Switching (GMPLS)
> Architecture
> > Author(s) : P. Ashwood-Smith et al.
>
> Wow. An I-D with 25 authors. I see we're starting to emulate the experimental
> physics community!
Noel, this falls so i
Is that a bit of chauvinism, Harald? :-)
D. Belsnes, "Single-Message Communication," IEEE Transactions on
Communication, Vol. TCOM -24, No. 2, pp. 190--194, February 1976.
> Please point to an example of a useful multipart message seen in
> this list or that might someday be useful in this mailing list.
I have sent to wg lists a multipart containing a preamble and an
internet-draft or similar file. This makes it easy for recipients to
save the draft as-is. Someti
> If DNSSEC were deployed, I see no reason why SAs could not be
> bound to domain names.
Well, there are all those load-distributing hacks -- Akamai and
others. But I bet they could come up with a huge flesh-tone bandaid
so you would continue not to notice. On a good day.
> > What is technically wrong with v6 that isn't already technically wrong
> > with v4?
>
> Thank you, Perry, you've put it in a nutshell.
> Noel
Excellent. We've agreed that IPv6's problems are a subset of IPv4's.
Now until we have a concrete design proposal for a perfect world
> But in retrospect, one thing he said bothered me greatly. He
> mentioned there were representatives of some five hundred different
> organizations at this meeting. That too is impressive. But it's
> that word "representative" I find disquieting.
>
> We are here not as corporate representa
> If the world had asked you or me to design an international
> language, I think either of us would have done better.
Don't be too sure. Even today, there are no more speakers of
Esperanto than of Mayan.
> Is the IETF now competing with scholarly journals in the race for
> ``most authors on a single paper''? (No offense intended to the
> parties listed above, but you'll pardon me if I get a little
> uncomfortable with the idea of a 29-page document having 26 official
> authors.)
Relax. For pers
Dave Andersen <[EMAIL PROTECTED]>, on behalf of "Nexsi
Corporation", has sent unsolicited job-recruitment spam to addresses
apparently gleaned from the posted IETF Nomcom volunteer list.
Form your own opinion. You can guess mine.
Matt Crawford
Consider the rather nasty attitude in response to my
technical deployment and utilization-scenario related
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
> B.t.w., does anybody know of a good (up-to-date) source of information that
> lists available IPv6 stack implementations ...
> I checked the IPNG working group site
> (http://www.ietf.org/html.charters/ipngwg-charter.html), but ...
Following the "Additional IPNGWG Page" link near the top of th
> What'd be better is for SOME organization, perhaps IANA, setting up one
> provider-sized block of addresses for early adopters to USE.
Hey, great idea! RFC 2471:
This document describes an allocation plan for IPv6 addresses to be
used in testing IPv6 prototype software. These addresses
> Brian Carpenter writes -
>
> | Please, please, nobody ever pick a prefix at random.
Sean Doran disingenuously writes:
> Why not? The chances of collision are quite small. Moreover, ...
For one reason (of several), who's going to delegate you the
reverse DNS (ip6.arpa) space to go with it?
> I have heard on some local (SF bay area) technology news reports that
> the Commission on Online Child Protection is looking at dividing the
> IPv6 address space into regions that can be classified according to
> their "safety" for child access.
THE CHILD ONLINE PROTECTION ACT (COPA) COM
> Does this mean that every router will have to handle 2^48 routing table
> entries and that this vast amount of information must be sent over the
> internet on every routing table update?
> Salavat
In a word, no.
In two words, Hell no!
See RFC 2374.
> Phone numbers have moved from being direct as originally implemented
> to being a level of indirection, thanks to a lot of behind-the-scenes
> mucking about. The Internet introduced DNS to gain that same level of
> indirection. Phone numbers are now portable; DNS names are portable.
I don't agr
> we will remove IPv6 router at the venue around 11:30. thanks.
> itojun
No, no -- thank YOU for providing it!
Also heard at the IETF: In the plenary session the chair
denied the existence of Ireland.
> > Its already set up link that, Not that I can ever recall seeing a .us.
>
> you have now.
> - Bill
And what was that nonsense they were spewing about www.state.us?
And if .us is "unusable", how did it get to be the third most common
country-code domain,
> Note that this is NOT spam! It's something funny - and so cool that you
> IETF people just need to see it. I just watched it three times in a row :)
> Besides being funny, it's a great way to teach your kids how the 'net
> works, too.
>
> http://www.warriorsofthe.net/
It's full of mistakes.
> Did the IESG depricate IP over Avian Carrier when I blinked?
> And the draft on IP over seismic waves is due any day now.
Consider the possibilities of a neutrino beam -- no media costs and
lower latency than direct point-to-point fiber.
http://www-numi.fnal.gov:8875/overview/overv
> actually I'd settle for well-defined mandatory labelling - at the SMTP
> level for big volume spammers and at the 822 level for everyone.
Perhaps a future First Lady Tipper Gore will try to help you out
there, as she did for the consumers of recorded music.
Around here, we've been warned agai
> *> 'RFC editor publishes' argument becomes less quibbly and arguably
> *> more futureproof.)
>
> The RFC Editor agrees with the futureproofing, ...
> folks have them buried in scripts, and pragmatic continuity is more
> valuable to the IETF membership than quibbling.
In other words, it's
As a linguistic exercise, you might reconcile this message, which you
get when you refuse to grant their applets read/write/delete/execute
access to all your files:
In order to run the Wimba forums application, you will need to
grant our applet a certain number of privileges. Our applet is
> The source address of a datagram was an architectural mistake, and should
> never have been in the mandatory packet format.
Nahh, the mistake was ignoring the source address when routing & forwarding.
u look upward two paragraphs from the part you quoted, you'll
see that "source address" does not mean the first address in the
fixed part of the IP header, but the address in the "route data"
provided by the source.
____
> If you send your nroff input file to the RFC editor as well as the
> nroff'd output file, which is the recommended practice, then modifying
> the ms macros themselves is not an option.
Well, sort of. You can .rm an existing macro and .de it differently.
I do that for the SH, H, XS, XA, XE, XE
Alan,
I'll send you my internet-draft nroff macros under separate cover.
(There's probably some internet obscenity law forbidding the
unsolicited transmission of nroff source.)
Matt
The magic word is "Content-Type: message/external-body".
> And remember, if we ever need to, we can start subnetting the bottom
> 64 bits, at the loss of one form of stateless autoconf (which I'm
> starting to find, in deployment, is too unpleasant to use on my nets anyway).
Ugh. Ick. You're not wrong, of course, but just ... "Yecchh."
> if it were easy to show this we would not be discussing the topic
> I don't know many companies who decide to do "*astonishingly*
> expensive" things if there are cheaper options
But they often do things that look cheap in the short run and then
discover the full cost later.
> > the idea is that IPv6 site renumbering will be so much easier than for
> > IPv4 that renumbering will be *less* painful than NATting.
>
> this needs to be reconciled with the *much* more conservative statements on
> v6 renumber-ability coming from respected v6 folk such as deering et alia.
W
> It seems to me that we may be able to recapture some aspects of end-to-end
> transparency at the application level if addressing issues are focused on
> host FQDNs, rather than IP addresses.
Forget about it. Many of the same folks doing NAT also do a
two-faced DNS which hides most of their nam
Well, they have to be there a lot more than you do! Ditto the
restaurant staff or the bus driver.
75 matches
Mail list logo
