the effort. To those whowere genuinely supportive of the authors'best
interests, my sincere thanks.
Fred L. Templin
[EMAIL PROTECTED]
Fred Templin [EMAIL PROTECTED] wrote:
Date: Wed, 10 Nov 2004 19:30:38 -0800 (PST)From: Fred Templin <[EMAIL PROTECTED]>Subject: Re: draft-ietf-ngtrans-isatap-22
Pekka Savola [EMAIL PROTECTED] wrote:
I can't figure how ICMPv6 could notice any further data corruption in any case, so I see no direct justification in *this* spec.)
We are speaking here about the case of the IPv6 layer noticing data corruption
in a received packet and then sending an ICMPv6
Pekka Savola [EMAIL PROTECTED] wrote:
I have no doubt that there may be link-layers which might detect or be able to detect corruption. But the typical approach then, AFAICS, is either to silently discard packet, or to try to retransmit at link-layer if there was a link-layer problem.
Persistent
I would like to see a new Code added to the Parameter Problem Message
Type ([ICMPv6], section 3.4) whereby the end host or a router on the path
can inform the source that unspecified data corruption was encountered
in the packet. The code definition should appear as a new item at the
end of the
Hello,
On August 23, 2004 I announced to this distribution a -00 document entitled:
"IPvLX: IPv6 Addressing in the IPv4 Internet"
Since that time, a -01 revision of thebase document has obsoleted the
-00 version, and a new document entitled: "IPvLX Errata" that specifies
patches to be applied
"Ghanwani, Anoop" [EMAIL PROTECTED] wrote:
This behavior is in conflict with Section 2.5.8 of RFC 2373 which states: "Routers must not forward any packets with link-local source or destination addresses to other links."
Coming from one who found out the hard way, the keyterms here
are: "routers"
Greg,
Thanks for the message. To clarify, however, IPvLX
*does not* propose to replace IPv6.
The IPvLX proposal incorporates IPv6 mechanisms as
core architectural elements.
Regards - Fred
[EMAIL PROTECTED]
--- Greg Daley [EMAIL PROTECTED] wrote:
Hi Fred,
(to the IPv6 wg only)
It may
[EMAIL PROTECTED] wrote:
In your opinion (no reasoning please), the rate limiting
configuration per-interface in the ICMPv6 spec should be a
1) SHOULD
2) MAY
3) Any of them is fine for you.
Bandwidth-based per-interface rate limiting is:
1) SHOULD
In other words, leave current text of [RFC2463],
Hello,
With Nokia hat off, I would like to announce a proposal for IPng
called: IPvLX - IP with virtual Link eXtension. See:
http://www.ietf.org/internet-drafts/draft-templin-ipvlx-00.txt
IPvLX uses IPv4 as an L2 protocol for network traversal and IPv6
as an L3 addressing protocol. It inserts an
Mukesh,
[EMAIL PROTECTED] wrote:
So are you saying that the ICMPv6 spec is talking about
rate limiting the ICMPv6 traffic that is being forwarded
by a router ?
If that is the case, Pekka is not alone. I also get the
perception that it is talking about generating the ICMPv6
messages and NOT
Pekka Savola wrote:
That's definitely out of scope of this *protocol* specification.
They're just forwarded IP packets. More often than not, the router
doesn't even know it's ICMPv6 (because it just looks at the
destination address), and *cannot* even know that (e.g., there are
extension headers,
Hello Mukesh,
[EMAIL PROTECTED] wrote:
Fred
If the router can know that they are error messages and can also know,
e.g., that the errors are arriving at a disproportionally
high rate with
respect to the IPv6 packets that could have possibly generated them,
then it should perform rate limiting.
Alex,
--- Alex Conta [EMAIL PROTECTED] wrote:
My concern is clarity.
The rate-limiting parameters SHOULD be configurable per node.
and/or per interface if the node has dissimilar speed/bandwidth interfaces.
is not clear enough.
The rate-limiting parameters SHOULD be configurable per
--- Pekka Savola [EMAIL PROTECTED] wrote:
On Mon, 16 Aug 2004, Alex Conta wrote:
The per node, and per interface mechanisms can coexist.
Sure. But why don't we just specify per node mechanisms, and leave it
up to the implementors if they wish to have per interface mechanisms
as well?
Stig Venaas wrote:
My thinking is:
M=0, O=0 stateless autoconf of addresses
M=0, O=1 stateless autoconf of addresses + information-request
M=1, O=0 stateful autoconf of addresses
It seems from these discussions that a more precise
representation might be:
M=0, O=0 stateless autoconf of addresses
No responses yet; for myself, I consider this subject as a
thoroughly-whipped dead horse. (Others are welcome to
continue, of course...)
Thanks - Fred
[EMAIL PROTECTED]
Fred Templin wrote:
Stig Venaas wrote:
My thinking is:
M=0, O=0 stateless autoconf of addresses
M=0, O=1 stateless autoconf
OK, I'll bite. Why all this talk about the global/split DNS,
and no talk about LLMNR?
Thanks - Fred
[EMAIL PROTECTED]
Dan Lanciani wrote:
Stephen Sprunk [EMAIL PROTECTED] wrote:
|I never intended locally-generated addresses to be in the global DNS, either
|forward or reverse, but there is nothing
Christian Huitema wrote:
On receipt of a valid Router Advertisement (as defined in
[DISCOVERY]), a host copies the value of the advertisement's M bit
into ManagedFlag, which saves the mostly recently received value of
the M bit. The details of how the host uses the
Ralph,
While the functions may be independent, wouldn't it be better
if we had a unified set of messages for accessing the functions?
(I'm thinking some sort of hybrid fusion of the RFC2461 ND
and RFC3315 DHCPv6 messages.) Perhaps it is too late in the
game to even consider this...
Fred
[EMAIL
Ralph Droms wrote:
Autonomous/managed or serverless/server-based might be more
correct...
If asked to vote on one of these two proposals, I would select
autonomous/managed; a node that is autonomous in terms
of address configuration might be a server for some other
function unrealted to
Hi Ralph,
A few quick follow-ups appear below:
Ralph Droms wrote:
Hi, Fred...
At 02:00 PM 3/23/2004 -0800, Fred Templin wrote:
Hi Ralph,
Ralph Droms wrote:
[...]
It seems the primary motivation for ND proxies is to avoid the need
for L3
devices that require configuration, prefix assignment
Ole Troan wrote:
I'd sure be interested in hearing what others in the WG think
on this issue.
I agree with Erik.
I see two alternatives:
1. ND proxy. Limited to single router, proxy from uplink to
downlink. No need for loop detection.
2. Multilink subnet routing. Handles arbitrary
, an explicit marker telling that there indeed
was a proxy would be quite useful for SEND.
The concern here is that the explicit marker may need to be carried
in all packets (not just ND packets) if there are asymmetric paths,
or if paths can change dynamically after the initial ND exchange.
Fred
Hi Ralph,
Ralph Droms wrote:
I reread draft-thaler-ipv6-ndproxy-02.txt, and wonder if it might be
time to
revisit the need for ND proxies.
Yes, I have been wondering the same thing - perhaps not for exactly
the same reasons.
It seems the primary motivation for ND proxies is to avoid the need
This discussion (and the bykim draft) reminds me of some materials
I briefed a long time ago during an NGTRANS session at IETF50:
http://6bone.net/ngtrans/IETF-50-Minneapolis/Templin-v6v4compat.ppt
(See slides #15-#19; note that the colors in the diagrams denote distinct
IPv6 prefix
Christian,
Christian Huitema [EMAIL PROTECTED] wrote:
We generally shied away from the second solution, and generally fromusing the host identification query to provide reverse mappings.
Is "host identification query" == "Node Information Queries" here?
Also, what about other non-DNS naming
If what you are both saying is correct, then perhaps either SEND
or ND-Proxy (or both) is only half-baked. Which one is it?
Fred L. Templin
[EMAIL PROTECTED]James Kempf [EMAIL PROTECTED] wrote:
Hi Erik, The fact that SEND doesn't currently provide security for proxy neighbor advertisements is an
All right then; I know what SEND is good for, so tell me what
ND proxy is good for (if what you are saying is true)?
Thanks - Fred
[EMAIL PROTECTED]Christian Huitema [EMAIL PROTECTED] wrote:
ND proxy is the equivalent of ARP spoofing.SEND is the antidote to ARP spoofing.Why should we be surprised
Tony,
I agree that 'draft-hain-templin-ipv6-localcomm' has served the useful
purpose of focusing the discussion, but (like an RFP or BAA) its sole
purpose was to issue a call for solution alternatives; not to propose
solution alternatives or otherwise seek a more active role in itself.
As such, I
Alain,
Speaking only as an individual wg participant, I appreciate the concerns
you are raising but am hoping that you are not contemplating a divisive
and time-consuming appeals process such as the one we have just come
through for site local deprecation.
Please consider that published documents
Bill,
Whether or not this would be new and untrodden, I believe
we need to step forward together into the unknown - under
the confidence that careful monitoring and any necessary
course-corrections will see us through the uncharted waters.
Regards,
Fred L. Templin
[EMAIL PROTECTED]
Bill Manning
Jinmei,
Do you have a timeframe for when you will be posting RFC2462(bis)
to the I-D repository?
Thanks - Fred
[EMAIL PROTECTED]JINMEI Tatuya / [EMAIL PROTECTED]@C#:H [EMAIL PROTECTED] wrote:
On Sun, 08 Feb 2004 09:02:54 -0500, Brian Haberman <[EMAIL PROTECTED]>said: Given my point above, I
Erik Nordmark wrote:
So do we or do we not want to
1. specify the per-interface router definition
2. specify how RFC 2461 (and 62) behave on a multihomed node
Well, from RFC 2460 we have:
+router - a node that forwards IPv6 packets not explicitly
+ addressed to
. So, unless someone can show
evidence of a reason to do so, let's keep the text straightforward
and as simple as possible.
Regards,
Brian
Pekka Savola wrote:
On Mon, 19 Jan 2004, Fred Templin wrote:
[...]
Assuming we are on the same page,
Yep.
there are two worst-case threat
models to consider
practical/operational aspects
that you bring to the discussion. Any suggestions on how to
proceed from here would be welcome.
Fred
[EMAIL PROTECTED]
Pekka Savola wrote:
On Mon, 19 Jan 2004, Fred Templin wrote:
[...]
Assuming we are on the same page,
Yep.
there are two worst-case threat
Pekka Savola wrote:
On Sun, 18 Jan 2004, Fred Templin wrote:
===
(f) Finally, in order to limit the bandwidth and forwarding costs
incurred sending ICMPv6 error messages, an IPv6 node MUST limit
the rate of ICMPv6 error
[EMAIL PROTECTED] wrote:
I agree with Pekka that this compllicates the text and the
implementation. Moreover, N (the long-term average) can be
in number of packets per seconds or a fraction of the attached
link's bandwidth. Don't you think, the size of the packet
will be covered if N is
Pekka Savola wrote:
On Mon, 19 Jan 2004, Fred Templin wrote:
Note: the decision whether or not to drop an incoming packet
can be made in packet mode, ignoring packet sizes, or in
byte mode, taking into account the size of the incoming
packet. The performance implications
Mukesh,
See comments below:[EMAIL PROTECTED] wrote:
Here is the final revision of the text that everyone seems to agree upon. I will put this in the draft. Please let me know if anyone has anymore comments on this. === (f) Finally, in order to
Pekka Savola [EMAIL PROTECTED] wrote:
On Tue, 13 Jan 2004, Fred Templin wrote: 10Kbps seems the best value for LCD, given commonly-deployed links that will see continued use into the future (see BCP documents produced by the PILC working group). .. that is, restricting mechanisms based
Hello,
Based on the concensus that appears to be emerging from the
ICMPv6 Rate Limiting Methods: Revised Text thread, it
seems to me (please correct me if I am wrong) that there is
no real compelling reason to make any changes to the existing
text of section 2.4 (f) found in the current
On further thought, the key words in the entire section of text we are talking
about are: "attached link's bandwidth". For interfaces that attach to the global
Internet, the "attached link" is the Internet itself and can be viewed as a
variable-bandwidth link with a wide range of bandwidth
Zachary Amsden wrote:
It seems to me that back to back is ill-defined. It is highly
unlikely that the ICMP error packets will be transmitted with no other
transmissions in between, which back to back seems to imply.
I am reading that text in a different way, and I believe the way
in which it
[EMAIL PROTECTED] wrote:
If Timer-based or Bandwidth-based function is chosen because of
the simplicity of implementation, proper care must be taken in
choosing the value of T or F. Values of T that are higher than
20-30 might break traceroute. A global value of F
Teemu,
ICMPv6 echo request/reply don't count, because they're not ICMPv6 errors.
If a well-behaved A is sending packets that cause B to generate ICMPv6 errors,
A will adapt its behavior and the ICMPv6 messages from B to A will naturally
subside. Can B be reasonably assured that A will be well
Pekka,
Mostly agree, except with the final paragraph where you say that
the parameters for token bucket, timer, etc. mechanisms don't
matter that much. ICMPv6 says that errors should include up to
the IPv6 min-MTU bytes of the packet that caused the error. That's
1280 bytes, but on some long,
information, especially in low-end routers. But, that's just an
off-the-cuff remark and not well thought out in terms of all
the implications.
Fred
[EMAIL PROTECTED]
Regards
Mukesh
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of ext Fred Templin
Sent: Wednesday
Mukesh
-Original Message-From: ext Fred Templin [mailto:[EMAIL PROTECTED]Sent: Wednesday, January 07, 2004 5:32 AMTo: Margaret Wasserman; Gupta Mukesh (Nokia-NET/MtView)Cc: [EMAIL PROTECTED]Subject: Re: draft-ietf-ipngwg-icmp-v3-02.txt: Rate Limiting Methods
Margaret,
On further consideration
Pekka,
Asterisks already appear all the time using 'traceroute'. That is why
three responses are solicited from each hop and the process proceeds
to the next hop even if only one response is received. (Indeed, many of
the traceroutes I have seen will "knock three times" repeatedly when a
Generally speaking, it seems appropriate to exclude implementation
alternatives only if they are known to cause operational issues. One
case of concern is that of a reflection attack in which an anonymous
attacker (A) using a spoofed source address (C) sends a stream of
malicious packets to a
Pekka,
Pekka Savola wrote:
On Tue, 6 Jan 2004, Fred Templin wrote:
Generally speaking, it seems appropriate to exclude implementation
alternatives only if they are known to cause operational issues.
[...]
Traceroute not working (without unnecessary delays) is a serious
operational
Hello Thomas,
I'm just returning from vacation and catching up, but it seems
to me that the packet size issue could become important if we
expect that the DNS will return many , A, etc. records
for some FQDNs. Are there any limits on the number of RRs
per FQDN that may be stored in the DNS?
The premises I'm working from are all in here:
http://www.ietf.org/internet-drafts/draft-hain-templin-ipv6-localcomm-04.txt
If you think there is something false about them, you'll have
to tell us all by way of commenting on the draft.
Thanks - Fred
[EMAIL PROTECTED]
Keith Moore wrote:
Fred,
Keith,
You are just plain wrong; read the Mirriam-Webster definitions
for terms like "organization", "enterprise", etc. then read:
http://www.ietf.org/internet-drafts/draft-hain-templin-ipv6-localcomm-04.txt
and you will see that "organizational scope" is the logical choice.
Fred
[EMAIL
As I said in my last message, my goal was to get a message out and
not push new terminology. I agree with Pekka that it doesn't matter at
all whether a router has just one interface or hundreds; it is still a
router.
(In fact, this is nearly the exact response I received when I asked a
related
type of solicitation.
I'm not necessarily trying to write the MAY/SHOULD/MUSTs
here; I'm simply identifying the need and soliciting input from
the wg; thanks for providing yours.
Fred
[EMAIL PROTECTED]
Pekka Savola wrote:
On Wed, 26 Nov 2003, Fred Templin wrote:
However, the message that must
Fred Templin wrote:
The two ways I see to do this are to either specify a new IPv6 ND option
(call it a Type II Router Solicitation for lack of a better name) or
to add
bits to the existing IPv6 Router Soliciation message (e.g., in the
Reserved
field) that indicate the type of information
to interoperable implementations.
I also wrote a document of my own that references Matt's
work and posted it to the I-D registrar. You can find a
copy in the interim at:
http://www.geocities.com/osprey67/isnoid-01.txt
Thanks - Fred
[EMAIL PROTECTED]
Fred Templin wrote:
Fred Templin wrote
The v6ops discussion from the 'draft-ietf-v6ops-mech-v2-01.txt' thread
took on an interesting twist that I felt warranted a new subject heading.
RFC 2461 specifies the behavior of traditional routers (i.e., ROUTERS).
ROUTERS typically advertise autoconfig parameters and prefixes from
their
The goal of my message is to get a message out; not to
push new terminology. See RFC 1122 for a discussion
of the "strong" vs "weak" ES models.
Thanks - Fred
[EMAIL PROTECTED]
[EMAIL PROTECTED]
Havard Eidnes [EMAIL PROTECTED] wrote:
I've heard in other discussions the distinction between
Eric,
EricLKlein wrote:
To be honest, as stated in another e-mail, I have not read the
draft-ietf-ipv6-unique-local-addr-01.txt, I am catching up on drafts and
will read it soon.
I'm a bit perplexed that you seem to have time to engage in
the e-mail discussions but have not yet found the time to
Keith,
Keith Moore wrote:
More on this point - I have two specific concerns about the use of
private addresses
1. potential confusion with RFC 1918 addresses, including the
association of RFC 1918 addresses with non-routable outside of the
local network and used with NATs.
2. potential
Hmm - so it seems that you *are* willing to go full circle
and spin in the rathole? Have fun, but please don't try to
take the wg with you; we have already spent way too
much time there.
Fred
[EMAIL PROTECTED]
Keith Moore wrote:
You are coming dangerously close to completing the full-circle
Keith,
GUPIs ("guppies") and PUPIs ("puppies") are things that little
children like to bring home from their local pet store.
IDEAs are things thatall Internet usersfrom the most seasoned
professional to the rankest novice immediately associate with
the pure essence of technology. The unspoken
I'll take mnemonic power, but could do without the cuteness.
How about:
IDEA - Independently-Delegated Endpoint Address
Fred
[EMAIL PROTECTED]
Keith Moore wrote:
I still prefer
GUPI (pronounced guppy like the fish) - globally unique
provider-independent
PUPI (pronounced puppy like a young
I havn't followed this discussion closely, but in my opinion
we have no business legislating anything stronger than a
MAY in relation to handling the M O bits in received
Router Advertisements. Sorry if this goes against other
opinions, but that's the way I see it.
Fred
[EMAIL PROTECTED]
[EMAIL
Eddie,
Yes, I agree with the idea of initially plumbing the path MTU
when a connection starts up. If the application has lots of data to
send, it might initially try to plumb out to the largest possible
MTU; if only a little, it might be less aggressive during startup.
It might also be desireable
Eddie,
Your opinion is from the perspective of a modern-day expert
technologist with specific insight into the problem space, and
I have a great deal of respect for that. My opinion brings an
historical perspective that I believe also bears consideration:
I was very close to ground-zero when the
Eddie Kohler wrote:
Well, I wouldn't want to be responsible for any further destruction of the
Internet revolution, but most of this seems besides the point. Old-style
PMTUD, which *depended* on the delivery of ICMPs, is a far cry from
new-style PMTUD, which *can benefit* from the delivery of
Pekka Savola wrote:
Hi,
well, the document seems like to completely concentrate on an
addressing-based solution model.. which it probably should not. Anyone
even glancing at the document can be 100% sure of this.
Or was it only supposed to be agnostic of whether local-use addressing was
Alain Durand wrote:
Tim Chown wrote:
I think we will see a lot of people using fd00::/48 or fd00::/64 for
their sites/links purely becuase it's less effort to type.
If this is the case, what will we have gained from fec0::/48?
One year of extremely heated discussion, appeal, gazillions
of
-use
type of document, e.g., a per-hop behavoir (PHB) document for
RFC 3168?
Thanks - Fred
[EMAIL PROTECTED]
Fred Templin wrote:
I hate to say it, but frankly I think this whole PMTU business is
a bunch of hooey. We have RFCs 1191 and 1981 as the service for
packetization layers that require network
coud after a short timeout try again with
Teredo.
I know that ISATAP has been seen as in the Enterprise
space, but I see potential applicability here for the
unmanaged. Comments?
Fred Templin
[EMAIL PROTECTED]
er a short timeout try again with
Teredo.
I know that ISATAP has been seen as in the Enterprise
space, but I see potential applicability here for the
unmanaged. Comments?
Fred Templin
[EMAIL PROTECTED]
Itojun,
I subscribe to the model that all nodes may indeed be routers.
This comes mainly from my background in MANET, but I see
the paradigm as possibly appropriate here as well. If each node
in the site were a router, we would be sending an RS in the
expectation of getting back an RA with
then.
See the "goals for local communications within sites" document
in the IPv6 space for other scenarios that would benefit from ISATAP.
Fred
[EMAIL PROTECTED]Pekka Savola [EMAIL PROTECTED] wrote:
I removed [EMAIL PROTECTED] from Cc: to avoid unnecessary cross-posting.On Thu, 13 Nov
I have one more update to share on this document. It is found at:
www.geocities.com/osprey67/tunnelmtu-05.txt
Changelog is below:
Fred Templin
[EMAIL PROTECTED]
Appendix A. Changelog o Removed support for IPv4 fragmentation to save state; eliminated control message overhead.
Fred Templin
e lowest-common denominator link that may occur over the tunnel, which is 296 bytes for a 9.6kbps link ([RFC3150], section 2.3)."
See:
www.geocities.com/osprey67/tunnelmtu-06.txt
Thanks - Fred
[EMAIL PROTECTED]Fred Templin [EMAIL PROTECTED] wrote:
I have one more update to share on this d
e comments. But,
the conclusions will not go away and are indeed inescapable.
Thanks - Fred
[EMAIL PROTECTED]
P.S. The document can be trivially extended to support IPv6
Jumbograms - this will be added in the next version.
Fred Templin [EMAIL PROTECTED] wrote:
As I said I would do in my 10/29
RFC 3582 says:
A "site" is an entity autonomously operating a network using IP, and in particular, determining the addressing plan and routing policy for that network. This definition is intended to be equivalent to "enterprise" as defined in [2].
where [2] refers to RFC 1918.
This is the
Mark,
Many of us have known about this work for a long time now. If
there are certain aspects of it you would like to call to our attention
(e.g., if there is a way for the lower layers to know when the upper
layers are doing PLPMTUD) please send specific details. In the
meantime, I will be
The same would work also for ISATAP (see: isatap.com), except
that ISATAP can use any IPv6 prefix, i.e., not just 2002::/16.
(Besides; 2002 was *last* year...)
Fred
[EMAIL PROTECTED]
Tim Chown wrote:
Hi,
Yes, this will work. This technique is quite widely used, and is one
reason for this
Umm - perhaps add a Changes since RFC 2461 section??
Fred
[EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
Title : Neighbor Discovery for IP version 6 (IPv6)
Author(s) : T. Narten, et. al.
83 matches
Mail list logo
