Hi.
If I understand what you are asking correctly, I think you have misread
RFC 2675/2460. The jumbogram option lives in the hop-by-by-hop
extension header (Header Type (Next header value) 0, option type code C2
hex). The routing header is a a different extension header (Header Type
43). J
I also think this is in good shape.
One addition that would be useful is to reference the v6ops security
overview (draft-ietf-v6ops-security-overview-06.txt currently in AUTH48
and about to be published as RFC 4942).
This also discusses security issues with RH0 (including the
amplification att
Hi.
Section 2.1.11 of the Security Overview draft
(http://www.ietf.org/internet-drafts/draft-ietf-v6ops-security-overview-06.txt)
discusses the 'tiny fragment' problem and tries to reflect Vishwas'
original concerns on tiny fragments (see the acknowledgments). After
some discussion on the ma
Tim Enos wrote:
From: Su Thunder <[EMAIL PROTECTED]>
Date: 2006/09/26 Tue AM 10:53:59 CDT
To: ipv6@ietf.org
Subject: A question about Source Address of IP Field of ND Packets(RFC2461)
The Source Address of Router Solicitation Message is specified in section
4.1 as follows:
IP Fiel
[EMAIL PROTECTED] wrote:
Hi all, as we all know Link Local addresses and communicating through them are
a must in an IPv6 environment. Without it Neighbor Discovery will not work and
so address resolution.
Our system enables one to set an MTU for and IPv6 address. So it is very much
possible
Templin, Fred L wrote:
Elwyn,
Maybe somebody ought to write a very short I-D just to set the record
straight.
It looks like there was at least one attempt to do that; see:
http://mirrors.isc.org/pub/www.watersprings.org/pub/id/draft-newman-netw
ork-byte-order-01.txt
I think Chr
After a little detective work:
The concept of a 'standard' (Internet) network byte order appears to
have crept into the RFC series without actually officially linking
Appendix B of RFC 791 (dated Sptember 1981) to the term.
AFAICS the earliest use of the term 'standard network byte order' is
Three suggestions:
Tim Chown's Campus Deployment guidelines:
http://www.ietf.org/internet-drafts/draft-chown-v6ops-campus-transition-03.txt
The Migration and transition cookbooks on the EU 6net site:
http://www.6net.org/
See also deployment guide on Publications page.
There may also be useful s
Hi.
Related matters have been discussed in connection with potential
security problems mainly on the v6ops list.
Some thoughts below...
Regards,
Elwyn Davies
Nuno Garcia wrote:
Hi there:
I believe the issue is not about fragmentation.
As RFC2460 stands at the moment, there is no
Hi.
Sorry for the silence.. I have been on an extended holiday jaunt and am
just catching up.
As one of those who commented on the current version, just to say that I
am happy with the proposed resolution, but it is probably appropriate to
add a security note as proposed by Jeroen Massar as
The router alert option has a rather more drastic effect than simply
having a h-b-h extension header. The intention of the h-b-h header (as
has been discussed recently in connection with a proposed QoS related
option) is that h-b-h options should, by default, not need to be
diverted to the 'sl
Suraj wrote:
Hi All,
RFC 2894 ' Router Renumbering for IPv6'describes the Renumbering of
Prefixes using RR commands to multicast addresses. (Site local OR Link
local).
Since the site local addresses are now deprecated (RFC 3879), we can
assume that RR is now supported only for Link local add
Dear IPv6 WG Chairs,
I previously sent this mail to the list at the time of the wg meeting in Paris
but there was no response. Has any decision been taken on how to move forward
with the IPv6 suite going towards full standard? I believe these items should
be looked at before RFC2460 goes forward
In the light of the previous discussion I had with Ron on this subject,
it occurs to me that it would address Ron's issue if responders joined
both the old 32 bit and the Solicited Node related multicast addresses.
Queriers that are worried about real time issues can use the new
Solicited Node
Elwyn Davies wrote:
Some comments:
<>
s6.4.1: [wish list] It occurs to me with the mention of tunnels that a
Qtype to find out about the addresses associated with (e.g.)
configured tunnels would be useful (v6 in v4 for example).
Brian asked me to propose some text for this. Here
Brian Haberman wrote:
On Aug 1, 2005, at 2:08, Pekka Savola wrote:
<>
Specifically, I'm very concerned about its use with global addresses,
over
the Internet. This has a potential to turn into a kitchen sink
protocol,
which can be used to do query anything at all from a random node.
Thi
Soliman, Hesham wrote:
All done, except:
> define the policy for the Neighbour Discovery options (since
> this hasn't
> previously been properly defined).
=> Did you mean the policy of allocating new option numbers?
Yes. I don't think this is covered elsewhere and there was no explic
Hi.
Having done a consistency check across all the ICMP updates, I believe
that the IANA considerations of this draft need an overhaul.
In particular:
- the master policies for types are (or will be) defined in the RFC that
comes from draft-ipngwg-icmp-v3 instead of RFC2780.
- this document n
Hi.
In the process of doing some checking on consistency of IANA
considerations across the various ICMP updates (while doing the ICMPv6
filtering bcp), I noticed that this draft has two minor IANA related issues:
- It should note that it updates RFC2780 as the new IANA considerations
replace s
al Message-
From: Elwyn Davies [mailto:[EMAIL PROTECTED]
Sent: Wednesday, July 20, 2005 11:29
To: [EMAIL PROTECTED]
Cc: Elwyn Davies; ipv6@ietf.org; Pashby, Ronald W CTR NSWCDD-B35
Subject: Re: Comments on draft-ietf-ipngwg-icmp-name-lookups-12.txt
JINMEI Tatuya / 神明達哉 wrote:
On Wed, 20 Jul
JINMEI Tatuya / 神明達哉 wrote:
On Wed, 20 Jul 2005 11:43:45 +0100,
Elwyn Davies <[EMAIL PROTECTED]> said:
As I said in my previous posting, I don't think you ought to think
of either solicited node multicast groups or these groups as
dynamically allocated. The g
Stig Venaas wrote:
Please don't send HTML, hard for me to read and quote.
Clients should definitely do an MLD join for this group (just as they
should for the solicited multicast address used for ND). My experience
is also that clients do join both the "solicited" and the "name-lookup".
I wou
JINMEI Tatuya / 神明達哉 wrote:
On Mon, 18 Jul 2005 14:13:54 -0500,
"Pashby, Ronald W CTR NSWCDD-B35" <[EMAIL PROTECTED]> said:
In the second paragraph of section 5 it reads:
"Compute the
I have just been reviewing the latest version of the name lookups draft and
checking the IANA considerations for that draft triggered me to look across the
IANA considerations for all the ICMPv6 stuff we have in progress at present.
The conclusions are:
- icmp-v3 supersedes section 7 in RFC2780
PS
s7: The IANA considerations should refer to the IANA considerations in 2463bis
(draft-ietf-ipngwg-icmp-v3-07.txt).
Some comments:
Substantive:
s4: Code 1 bullet point: The 'Supported Qtypes' query disappeared from
the rest of the memo some time ago.
s5: para 5: Is the intended effect of t
Some comments:
Substantive:
s4: Code 1 bullet point: The 'Supported Qtypes' query disappeared from
the rest of the memo some time ago.
s5: para 5: Is the intended effect of the last sentence (defaulting to
accepting all link-local multicast addresses that have been joined) that
sending a NOO
Consider:
- The primary point of RFC3307 is to make sure that you can get a unique
IPv6 multicast address - The Layer 2 non-clash is a bonus.
- The addresses are (probably) not taken from the spaces to which
RFC3307 applies (they are 'traditional' P=0 addresses - I believe the
intent was that R
interoperability - we know that they don't have to and can say
so in one short sentence!
Brian Haberman wrote:
On Jul 12, 2005, at 3:49, Elwyn Davies wrote:
I was thinking of something along the lines of:
...joining and leaving the solicited-node multicast group SHOULD be
done using MLD v1 [MLD]
I was thinking of something along the lines of:
...joining and leaving the solicited-node multicast group SHOULD be done
using MLD v1 [MLD] or v2 {RFC3810]. Section 8 of [RFC3810] explains how
nodes using MLDv1 and MLDv2 can coexist on a link.
Elwyn
Soliman, Hesham wrote:
> This is a very p
This is a very purist view. Even if you don't tell them what to do, at
least give them a hint that they ought to think about the issue.
I suggest you put in a pointer to s.8 of 3810.
Regards,
Elwyn
Soliman, Hesham wrote:
> > My understanding that as well as a reference to MLDv2 we
> would ne
My understanding that as well as a reference to MLDv2 we would need to
mention that if any of the routers are 'legacy' that support only MLDv1,
then any MLDv2 routers would have to have their configuration flags set
to make them operate in MLDv1 compatibility mode. Hosts on the other
hand will
can only be handled by providing a configuration flag
which would tell an interface to send MLDv2 Listener Reports instead of
MLDv1 ones.
Regards,
Elwyn Davies
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative
Hi, Fernando,
Looking back at the ICMPv6 draft, in the light of this, there are a number
of sanity checks that could be performed on returning error messages to
minimise security risks.
For example:
In draft-gont-tcpm-icmp-attacks-03.txt, the 'port unreachable' error is
cited as possibly being cl
(As party to the discussion which produced this new text) I don't believe
that this alters the current state of affairs significantly. If the ICMPv6
message is coming from the destination node it is (still) required by 2.2(a)
to use the destination adddress of the original message as source. Th
Sorry this is very late... don't know if you are updating the draft ...
Comments below... essentially go ahead.
Regards
elwyn
> -Original Message-
> From: Mukesh Gupta [mailto:[EMAIL PROTECTED]
> Sent: 03 February 2005 04:43
> To: [EMAIL PROTECTED]
> Cc: ipv6@ietf.org
> Subject: GEN-ART
Hi.
Overall this should be out there rsn.
However, there are is one point that needs clearing up in the estimation of
collision probability (S3.2.3):
In para 2 (above the formula), N is stated to be the total number of such
IDs whereas in parentheses after the formula N is defined to be the numbe
The revised wording for (d) (with s/by the same/with the same/) looks OK
but doesn't cover the other corner case for 2.2(b).
Elwyn
At 10:43 12/01/2005, [EMAIL PROTECTED] wrote:
Elwyn & Pekka,
> In that case, I guess (d) would have to be reworded to better match
> reality, for example, from:
>
>
Elwyn
-
Elwyn Davies
Consultant
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oykingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
IE
Title: RE: Last call comments for draft-ipngwg-icmp-v3-05
Mukesh,
Sorry for the delay in replying.
Responses in line...
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 09 November 2004 00:10
> To: Davies, Elwyn [HAL02:0S00:EXCH]; [EMAIL PROTECT
Hi Mukesh.
Responses in-line...
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 05 November 2004 21:32
> To: Davies, Elwyn [HAL02:0S00:EXCH]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: Last call comments for draft-ipngwg-icmp-v3-05
>
>
> Hi
Various points...
Section 1: The first sentence (The Internet Protocol, version 6 (IPv6) is a
new version of IP.) is not really useful for an ongoing standards document,
and could be deleted without loss.
Section 2.1 would be better split into three sections and reordered - it
covers three thin
looking back at the text in S2.2, the reason for using multicast-capable
rather than just multicast was that multicast-capable was (i think) supposed
to cover both multicast links which have native support and point-to-point
links which do multicast degenerately. i think that my problem could be
s
Hi.
Using the term 'multicast services' around this area is confusing. If the
link MUST provide multicast services maybe that is something that should be
in the basic definition of IPv6 (it isn't stated explicitly in RFC2460)
rather than in 2461bis.
Expanding on what I said originally, one reaso
Hi.
Quoting from S5.2:
Next-hop determination for a given unicast destination operates as
follows. The sender performs a longest prefix match against the
Prefix List to determine whether the packet's destination is on- or
off-link. If the destination is on-link, the next-hop address
Hi.
Quoting from S5.2:
Next-hop determination for a given unicast destination operates as
follows. The sender performs a longest prefix match against the
Prefix List to determine whether the packet's destination is on- or
off-link. If the destination is on-link, the next-hop address
Title: RFC2461bis: Multicast capable vs Multicast Service [was RE: Comments for rc2461bis]
Hi.
Using the term 'multicast services' around this area is confusing. If the link MUST provide multicast services maybe that is something that should be in the basic definition of IPv6 (it isn't stat
Hi, Hesham,
Thanks for the updates - for the majority I'll check the draft when it
appears.
I split out the multicast and prefix issues into separate threads.
Regards,
Elwyn
PS
Hope my stupid mail server remembers to send this as plain text.
E
-Original Message-
From: Soliman, Hesham
While writing the recent draft on NAT-PT deprecation, I had occasion to
review RFC1838 and RFC3128 which relate to security threats with fragmented
IPv4 packets. One of the problems was that the IPv4 specification allowed
for fragments to overlap. It appears that the general assumption is that
IP
MAIL PROTECTED]]
> Sent: 03 September 2004 11:21
> To: Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: new rev. of rfc2462bis will be coming
>
>
> >>>>> On Fri, 3 Sep 2004 11:57:36 +0200 ,
> >>>>> &qu
Title: RE: new rev. of rfc2462bis will be coming
Getting the wording right without creating double maintenance is a problem.
The point is that an address prefix only specifies the (prefix length) left most bits. RFC3513 has examples with essentially arbitrary bits to the right of the prefix
Title: RE: new rev. of rfc2462bis will be coming
Sorry - I spotted a couple of other points (updated):
In Section 5.3:
A link-local address is formed by prepending the well-known
link-local prefix [RFC3513] (of appropriate length) to the interface
identifier. If the interface ide
Title: RE: new rev. of rfc2462bis will be coming
Sorry - I spotted a couple of other points:
In Section 5.3:
A link-local address is formed by prepending the well-known
link-local prefix [RFC3513] (of appropriate length) to the interface
identifier. If the interface identifier ha
Title: RE: [rfc2462bis #596] definition of "multicast-capable"
Unfortunately the links are not specified - 2461 says ND applies to all links unless the link specific doc says otherwise (see the Intro to 2461/2461bis).
So I suggest in place of..
The links on which the protocol used in this doc
Title: RE: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
(B
(B
(B
(B
(BOk - that is true - this is a non-issue here at present.
(B
(B
(B[After some study of the email trails on ULA, I can't see there was resolution of the discussion of how to handle address selection when ULA and truly glob
gt; Sent: 19 August 2004 09:26
> To: Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
>
>
> >>>>> On Wed, 18 Aug 2004 17:43:39 +0100,
> >>>>> "Elwyn Davies"
N:draft-ietf-ipv6-rfc2462bis-05.txt
>
>
> >>>>> On Wed, 18 Aug 2004 17:09:37 +0100,
> >>>>> "Elwyn Davies" <[EMAIL PROTECTED]> said:
>
> > The problem is the use of the term 'global' - address
> auto-configuration
&
16:33
> To: Davies, Elwyn [HAL02:0S00:EXCH]
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
>
>
> >>>>> On Wed, 18 Aug 2004 15:57:00 +0100,
> >>>>> "Elwyn Davies" <[EMAIL PROTECTED]>
ED]'
> Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
>
>
> One more "easy" point:
>
> >>>>> On Mon, 16 Aug 2004 18:43:04 +0100,
> >>>>> "Elwyn Davies" <[EMAIL PROTECTED]> said:
>
> >> > As ment
ED]'
> Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
>
>
> I'm replying to some of the other points you made. I guess we may
> need a separate discussion for the rest, so I'll create dedicated
> entries for them in the issue tracker.
>
> >>>
; Cc: '[EMAIL PROTECTED]'
> Subject: Re: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
>
>
> Some quick clarifications:
>
> >>>>> On Mon, 16 Aug 2004 18:43:04 +0100,
> >>>>> "Elwyn Davies" <[EMAIL PROTECTED]> said:
>
oints in parallel of IESG
> evaluation. If anyone of you disagrees with this, please speak up
> right now (then I'll try to address the issues quickly and revise the
> draft once again).
>
> >>>>> On Fri, 13 Aug 2004 22:24:01 +0100,
> >>>>> &qu
Title: RE: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
Its hard to keep up with the versions of this draft;-)
I take it that -05 is merely the complete version of -04 - I can't see any difference.
So here goes with my comments that were intended for -04.
==
Title: RE: I-D ACTION:draft-ietf-ipv6-rfc2462bis-05.txt
Its hard to keep up with the versions of this draft;-)
I take it that -05 is merely the complete version of -04 - I can't see any difference.
So here goes with my comments that were intended for -04.
==
Title: RE: Stateful != M , Stateless != O
Having been reviewing the combined ICMPv6 drafts and following this thread, I would support Stig's ideas here.
The wording around 3315/3736 needs to be cleared up because a naive reader *would be* confused by the juxtaposition of 'stateful', 3736 and
Title: Comments for rc2461bis
I just went through 2461bis having not looked in detail for a while.
The intention was to check consistency and comprehensibility for those not so close to the subject.
Editorial nits:
S2.1: Last item (random delay seed) - missing newline so title of definition
biguous by construction, since they refer by definition to any
host that has been assigned a given anycast address. Link-local or
global anycast addresses can be"baked in the code".
missing space
Regards,
Elwyn Davies
> -Original Messag
66 matches
Mail list logo
