headers
Rob Austein | 3 Jul 2005 06:00
Favicon

Weekly posting summary for ipv6 <at> ietf.org

    Messages   |      Bytes        | Who
--------+------+--------+----------+------------------------
 25.00% |    4 | 26.55% |    20004 | cnugoud <at> gmail.com
 12.50% |    2 | 12.63% |     9513 | jeroen <at> unfix.org
 12.50% |    2 | 12.58% |     9480 | francis.dupont <at> enst-bretagne.fr
  6.25% |    1 |  9.07% |     6831 | chenhongfei <at> huawei.com
  6.25% |    1 |  8.12% |     6116 | internet-drafts <at> ietf.org
  6.25% |    1 |  6.12% |     4612 | mukesh.k.gupta <at> nokia.com
  6.25% |    1 |  5.28% |     3980 | jinmei <at> isl.rdc.toshiba.co.jp
  6.25% |    1 |  5.17% |     3893 | yoshfuji <at> linux-ipv6.org
  6.25% |    1 |  5.05% |     3801 | yuxuanqk <at> 126.com
  6.25% |    1 |  4.80% |     3615 | mailman-owner <at> ietf.org
  6.25% |    1 |  4.63% |     3491 | sra+ipng <at> hactrn.net
--------+------+--------+----------+------------------------
100.00% |   16 |100.00% |    75336 | Total

Grunchweather Associates provides this automatic summary on an at-whim
basis at the request of the IPv6 WG chairs.  Your mileage may vary.
We decline responsibilities, all shapes, all sizes, all colors.
If this script produces broken output, you get to keep both pieces.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 0 comments |
headers
kishore mundra | 5 Jul 2005 11:11

RE: IPv6 Extension Headers

Hi srinivas,

The destination option header which is coming before routing header is meant
for both the final destination and the intermediate destinations. The
destination header which is coming just before the upper layer header (i.e.
Final Header) is only for the final destination.

Home Address Option is meant for MIPv6 support. In case you are not
supporting it, you need not bother about it.

Regards,
Kishore.

-----Original Message-----
From: ipv6-bounces <at> ietf.org [mailto:ipv6-bounces <at> ietf.org] On Behalf Of
Srinivas Goud
Sent: Wednesday, June 29, 2005 1:18 PM
To: Francis Dupont
Cc: ipv6 <at> ietf.org
Subject: Re: IPv6 Extension Headers

Hi Francis, 
Thank you very much for the information.  I am proceeding with the
implementation. How do we distinguish the destination options? 
(intermediate destination / home address destination / final destination)

As per my understanding intermediate destination is the one which is coming
before routing header and final destination is the one which is coming after
routing header. Is my understanding correct?  
I am not having clear idea about home address option.
(Continue reading)

Permalink | Reply | 0 comments |
headers
The IESG | 7 Jul 2005 00:14
Picon
Favicon

Protocol Action: 'IPv6 Host to Router Load Sharing' to Proposed Standard

The IESG has approved the following document:

- 'IPv6 Host to Router Load Sharing '
   <draft-ietf-ipv6-host-load-sharing-04.txt> as a Proposed Standard

This document is the product of the IP Version 6 Working Group Working Group. 

The IESG contact persons are Margaret Wasserman and Mark Townsley.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-host-load-sharing-04.txt

Technical Summary

The original IPv6 conceptual sending algorithm does not do load-
sharing among equivalent IPv6 routers, and suggests schemes which
can be problematic in practice.  This document updates the
conceptual sending algorithm so that traffic to different
destinations can be distributed among routers in an efficient
fashion.

Working Group Summary

The IPv6 working group has done extensive review of this document and
this document reflects the consensus of the group.

Protocol Quality

This document has been reviewed by members of the ipv6 <at> ietf.org
mailing list and by the working group chairs.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Margaret Wasserman | 7 Jul 2005 05:41
Favicon

NEW!! Internet Area Mailing List


[This message is bcc:ed to all INT area WGs, the IESG and the IAB.]

Hi All,

We have created an Internet Area mailing list -- int-area <at> ietf.org. 
This list will be used to announce Internet area BOFs, to discuss 
Internet area WG charter updates and to discuss other issues related 
to the Internet Area, as they arise -- such as whether we should hold 
an Internet area meeting in Paris.

If you wish to join the list, you can do so at:

https://www1.ietf.org/mailman/listinfo/int-area

The archives should be available at:

http://www.ietf.org/mail-archive/web/int-area/index.html

(Hopefully this will be the first message in the archive).

If you are interested in issues concerning the overall structure or 
scope of the Internet area and/or are interested in influencing how 
the Internet area is managed, I hope you will join this list.

Thanks,
Margaret

--------------------------------------------------------------------
IETF IPv6 working group mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Kempf | 7 Jul 2005 18:46

ICMP Security Problem?

A friend sent me this reference. I have not looked into this in detail, so
this may be a well-known problem:

http://kerneltrap.org/node/5382

Any comments?

            jak

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 4 comments |
headers
Bob Hinden | 7 Jul 2005 18:58
Picon

Re: ICMP Security Problem?

James,

At 09:46 AM 07/07/2005, James Kempf wrote:
>A friend sent me this reference. I have not looked into this in detail, so
>this may be a well-known problem:
>
>http://kerneltrap.org/node/5382

There is a thread on /. about this today as well.  I think most of this is 
old news.  The new ICMPv6 update that is being worked on has a major 
revision to the Security Considerations section that should cover these 
issues.  If I remember correctly, the work in V6OPS that the article refers 
to was fed into the new ICMPv6 draft.

Bob

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Permalink | Reply | 3 comments |
headers
Lowe Chris | 7 Jul 2005 20:13

RE: ICMP Security Problem?

Bob--

  Slashdot is posting old news???  That is so unusual!  ;) 

Chris

-----Original Message-----
From: ipv6-bounces <at> ietf.org [mailto:ipv6-bounces <at> ietf.org] On Behalf Of
Bob Hinden
Sent: Thursday, July 07, 2005 12:59 PM
To: James Kempf
Cc: IPV6 WG
Subject: Re: ICMP Security Problem?

James,

At 09:46 AM 07/07/2005, James Kempf wrote:
>A friend sent me this reference. I have not looked into this in detail,

>so this may be a well-known problem:
>
>http://kerneltrap.org/node/5382

There is a thread on /. about this today as well.  I think most of this
is old news.  The new ICMPv6 update that is being worked on has a major
revision to the Security Considerations section that should cover these
issues.  If I remember correctly, the work in V6OPS that the article
refers to was fed into the new ICMPv6 draft.

Bob
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fernando Gont | 7 Jul 2005 21:18
Picon
Favicon

Re: ICMP Security Problem?

At 01:58 p.m. 07/07/2005, Bob Hinden wrote:

>>A friend sent me this reference. I have not looked into this in detail, so
>>this may be a well-known problem:
>>
>>http://kerneltrap.org/node/5382
>
>There is a thread on /. about this today as well.  I think most of this is 
>old news.

The attacks are not new, and that's acknowledged in the draft. However, 
there were not counter-measures for them.
Have a look at the NISCC and CERT/CC vulnerability reports, and see the 
number of implementations affected.

>The new ICMPv6 update that is being worked on has a major revision to the 
>Security Considerations section that should cover these issues.

Yes. We discussed this some time ago, and Mukesh has already addressed 
these issues in the ICMPv6 update.

>If I remember correctly, the work in V6OPS that the article refers to was 
>fed into the new ICMPv6 draft.

I don't think so. However, the current ICMPv6 update defines the semantics 
of ICMPv6 error messages, and thus allows anything that runs over IPv6 to 
handle ICMP error messages in what they think is the best way. Thus 
allowing the "TCP's reaction to soft errors" thing to be implemented 
without violating the specs (as is the case with IPv4), for example.
(Continue reading)

Permalink | Reply | 0 comments |
headers
fujisaki | 8 Jul 2005 10:04

Web Page for distibution of the default address selection policy.


Hi all,

Related to our proposed draft:

  Title:   Distributing Default Address Selection Policy using DHCPv6
  Filename: draft-fujisaki-dhc-addr-select-opt-00.txt

we've summarized the current implementation status of RFC3484, our
proposing mechanism for distributing RFC 3484 policy table, and its
practical usages in our web page: 

	   http://www.nttv6.net/dass

As you know, RFC3484 provides a very powerful function, and we believe
our distribution mechanism of the policy table in this RFC will be
quite useful.

Above page is not complete yet, so we'll appreciate if you give us 
any suggestions or comments on our draft and web page.

Yours sincerely,

--
Tomohiro Fujisaki

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Fenner | 8 Jul 2005 18:16
Picon

Re: Move forward with scoped literal URI format?


>So, I guess the appropriate next step for this work is to make
>consensus on this, which mostly equals to my question -1:
>
>  -1. are we okay with forcing URL/URI parsers to understand the
>      detailed semantics of the scoped address syntax and to strip the
>      zone ID (+ delimiter) part by itself for the reason because the
>      parsers would already need to do some extra work for the special
>      syntax?

Obviously, since I proposed it, I'm OK with it.  I haven't seen anyone
else with an opinion.

Overall, I've seen a handful of "I need this" and one "I've
implemented this", lots of misunderstanding about what the
proposal is, and a handful of "There's no use for this."
There's been some discussion of what the seperator character
should be, which is fine but irrelevant if the answer to the bigger
question is "no".

Since the majority of the comments since the IETF meeting have
been negative, I'm inclined to drop this work.  I still think it's
necessary, but if the major players in the WG push against it then
I'm not going to pursue it.

  Bill

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
(Continue reading)

Permalink | Reply | 0 comments |

Gmane