蒋胜 | 3 Jul 04:05 2007

CGA configuring draft submitted

Dear all,

A new CGA configuring draft has been submitted to IETF Internet Draft, see
the attachment too. It mainly analyzes the requirements for the
configuration CGA Multi-key CGAs (MCGA). Additionally, the applicability of
Router Advertisement and DHCPv6 for performing this configuration is
discussed.

Comments are welcomed. 

Best regards,

Dr. Sheng JIANG

IP Research Department, Networking Research Department, Network Product
Line, Huawei Technologies Co. Ltd.
Network Working Group                                          Sheng Jiang 
Internet Draft                                            Sam(Zhongqi) Xia 
Expires: December 2007                        Huawei Technologies Co., Ltd 
                                                   Alberto Garcia-Martinez 
                                                                      UC3M 
                                                            July 2nd, 2007 

                                   
   Requirements for configuring Cryptographically Generated Addresses (CGA) 
            and overview on RA and DHCPv6-based solutions 
               draft-jiang-sendcgaext-cga-config-00.txt 

(Continue reading)

Iljitsch van Beijnum | 3 Jul 18:17 2007

draft-van-beijnum-multi-mtu-00

First of all: this message is going out to the IPv6 wg and internet  
area mailinglists (for reasons explained below) but it's not  
crossposted, so replies will go to the list where you found it by  
default unless you add the other one yourself.

The internet-drafts administrator was kind enough to publish the  
following draft:

http://www.ietf.org/internet-drafts/draft-van-beijnum-multi-mtu-00.txt

The idea here is to lift the limitation that all nodes connected to a  
subnet must all use the same MTU by adding mechanisms to negotiate  
the use of bigger packets between two nodes. Hopefully, this will  
make it possible to start increasing the MTU on many links that make  
up the internet. Currently, there is some form of ethernet in almost  
all paths across the internet, and all forms of ethernet use an MTU  
of 1500 bytes, even though gigabit ethernet hardware generally  
supports larger sizes. The problem is that switches can't fragment  
and ethernet is stateless so the IEEE can't mandate larger packet  
sizes for faster ethernet. But IP can fragment, or, more generally,  
adjust the packet size, and has at least some per-neighbor state so  
we can solve this at the IP layer.

Ultimately, the idea is that this will work for both IPv4 and IPv6.  
So at a high level, this would be an appropriate discussion topic for  
the internet area list.

However, IPv4 doesn't have many hooks where new options can be added  
easily like IPv6, so I'm focussing on IPv6 at this time. The draft  
specifies:
(Continue reading)

Bernard Aboba | 3 Jul 23:05 2007

Consideration of draft-lior-radius-attribute-type-extension-02.txt

The RADEXT WG has a charter deliverable for extensions to the RADIUS 
attribute space. The apparent consensus in the WG is to solve a very 
simple set of problems, including the pending exhaustion of the standard 
RADIUS attribute space, a consistent mechanism for application layer 
fragmentation and reassembly for Diameter interoperability, and a 
consistent mechanism for grouping of attributes for data structuring, 
also for Diameter interoperability. 

The structure of the extended attribute format currently under 
consideration may require changes in various RADIUS extensions drafts 
in RADEXT and other working groups. This assumes that at least some of 
these documents will ultimately use the RADIUS extended attribute 
allocations. Given the potential widespread impact of attribute 
extension, the RADEXT WG Chairs are requesting that the RADEXT WG and 
all other affected WGs please review the following document: 
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-02.txt

This is the third (and last) review request relating to this document.  
On December 5, 2006 a call for review of the RADIUS extended attribute 
document was issued to the RADEXT WG:  
http://ops.ietf.org/lists/radiusext/2006/msg01002.html

Unfortunately, no review comments were received relating to this document.  
Since the call for review occurred during the holiday the call for review 
was reissued on March 20, 2007:
http://ops.ietf.org/lists/radiusext/2007/msg00161.html

This request did not garner much response either, so the call for review 
is being reissued one last time, in order to gauge whether there is 
sufficient interest in this work item. 
(Continue reading)

Bernard Aboba | 3 Jul 23:01 2007
Picon

Consideration of draft-lior-radius-attribute-type-extension-02.txt

The RADEXT WG has a charter deliverable for extensions to the RADIUS attribute
space. The apparent consensus in the WG is to solve a very simple set of
problems, including the pending exhaustion of the standard RADIUS attribute
space, a consistent mechanism for application layer fragmentation and reassembly
for Diameter interoperability, and a consistent mechanism for grouping of
attributes for data structuring, also for Diameter interoperability.

The structure of the extended attribute format currently under consideration
may require changes in various RADIUS extensions drafts in RADEXT and
other working groups. This assumes that at least some of these documents
will ultimately use the RADIUS extended attribute allocations. Given the
potential widespread impact of attribute extension, the RADEXT WG Chairs
are requesting that the RADEXT WG and all other affected WGs please review
the following document:
http://www.ietf.org/internet-drafts/draft-lior-radius-attribute-type-extension-02.txt
 
This is the third (and last) review request relating to this document. 
On December 5, 2006 a call for review of the RADIUS extended attribute document was
issued to the RADEXT WG:  http://ops.ietf.org/lists/radiusext/2006/msg01002.html

Unfortunately, no review comments were received relating to this document.  Since the call
for review occurred during the holiday the call for review as reissued on March 20, 2007:
http://ops.ietf.org/lists/radiusext/2007/msg00161.html
 
This request did not garner much response either, so the call for review is being
reissued one last time, in order to gauge whether there is sufficient interest in this work item.
 
Please send comments to the RADEXT WG mailing list (radiusext <at> ops.ietf.org)
indicating whether you believe the document should be adopted as a RADEXT WG
work item.  You need not have any comments on the document in order to respond
affirmatively;  however, if you do not believe the document should be adopted, it would
be helpful to explain why not.  If there are specific issues relating to the document,
these should be submitted using the RADEXT Issue Tracker template, which can be found at:
http://www.drizzle.com/~aboba/RADEXT/
 
This Request for Review will last until July 22, 2007.
_______________________________________________
Int-area mailing list
Int-area <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area
Jari Arkko | 21 Jul 18:03 2007
Picon

Agenda for the Internet Area open meeting

INTAREA
Internet Area Open Meeting

MONDAY, July 23rd, 2007
1520-1720 Afternoon Session II
Red Lacquer

Area Directors: Jari Arkko and Mark Townsley

1. Notes takers, blue sheets, agenda bash (5 min)

2. Area status update (ADs, 10 min)
    - BOF situation
    - Major WG news
    - "area drafts" and their status

3. DHCP authentication discussion update (Ralph Droms, 5 min)

   - Summary of discussion so far

4. Multiple MTUs (Iljitsch van Beijnum, 20 min)

   http://www.ietf.org/internet-drafts/draft-van-beijnum-multi-mtu-00.txt

   - Reporting possible new work

5. Update on routing and addressing discussions (Lixia Zhang, 10 min)

6. Denial-of-service - any possibilities for new IETF work?
   (Mark Handley, 30 min)

7. Wrap-up / open-mike
Jari Arkko | 22 Jul 23:52 2007
Picon

Re: Agenda for the Internet Area open meeting

Take two:

INTAREA
Internet Area Open Meeting

MONDAY, July 23rd, 2007
1520-1720 Afternoon Session II
Red Lacquer

Area Directors: Jari Arkko and Mark Townsley

1. Notes takers, blue sheets, agenda bash (5 min)

2. Area status update (ADs, 10 min)
    - BOF situation
    - Major WG news
    - "area drafts" and their status

3. DHCP authentication discussion update (Ralph Droms, 5 min)

   - Summary of discussion so far

4. Multiple MTUs (Iljitsch van Beijnum, 20 min)

   http://www.ietf.org/internet-drafts/draft-van-beijnum-multi-mtu-00.txt

   - Reporting possible new work

5. Update on routing and addressing discussions (Lixia Zhang, 10 min)

6. Denial-of-service - any possibilities for new IETF work?
   (Mark Handley, 30 min)

7. IPv4 address space situation (Geoff Huston ,30 min)

8. Wrap-up
Jari Arkko | 23 Jul 12:01 2007
Picon

Re: Re: Agenda for the Internet Area open meeting

Take three:

INTAREA
Internet Area Open Meeting

MONDAY, July 23rd, 2007
1520-1720 Afternoon Session II
Red Lacquer

Area Directors: Jari Arkko and Mark Townsley

1. Notes takers, blue sheets, agenda bash (5 min)

2. Area status update (ADs, 5 min)
    - BOF situation
    - Major WG news
    - "area drafts" and their status (see slides,
      not presented)

3. SAVA update (Mark Williams, 5 min)

   - New direction

4. DHCP authentication discussion update (Ralph Droms, 5 min)

   - Summary of discussion so far, call for joining the discussion
     on the list

5. Multiple MTUs (Iljitsch van Beijnum, 20 min)

   http://www.ietf.org/internet-drafts/draft-van-beijnum-multi-mtu-00.txt

   - Reporting possible new work

6. Update on routing and addressing discussions (Lixia Zhang, 10 min)

   - Invitation to join RRG meeting on Friday 0900-1700

7. Denial-of-service (Mark Handley, 30 min)

   - Any possibilities for new IETF work?

8. IPv4 address space situation (Geoff Huston, 30 min)

   - Reporting the situation

9. Wrap-up
Thierry Ernst | 23 Jul 23:43 2007
Picon
Picon

About MANEMO and interoperability between mobility solutions


In Prague, MANEMO was discussed during the NEMO WG slot, and 2 bar BOFs
also took place.

This time, MANEMO was discussed during the Autoconf WG slot.

One conclusion is that MANEMO spams across several WGs (possibly across
several areas too), and it was pointed out that whatever the use cases
are, NEMO and MANET (and the other IETF effort) should be interoperable.

So I'm wondering why don't we discuss MANEMO on this list and during
the Int-Area meeting.

This topic could be further extended to simply discuss interoperability
between all the mobility protocols (NEMO, MANET, P-MIP, FMIPv6,
HMIPv6, MANEMO, ....).

I think Int-Area is the right place to clarify the interaction between
WGs. 

Thierry.
Iljitsch van Beijnum | 24 Jul 01:46 2007

Larger MTUs

[see conclusion at the end if you skip some stuff]

After the feedback this afternoon I read RFC 4821, which is about  
discovering the path MTU by probing rather than depending on ICMP  
messages.

This approach has the advantage that it can work just as well over a  
layer 2 path with an unknown MTU as over a layer 3 path where  
traditional path MTU discovery doesn't work because ICMP "too big"  
messages aren't sent or received.

This means that it would be possible for hosts implementing this  
mechanism to simply set the maximum MTU search size to their local  
non-standard MTU and everything will work.

In my approach, I wanted to avoid sending oversized packets that  
don't make it through the layer 2 network as much as possible to  
avoid the problems this may cause. In the degenerative case, a  
10/100/1000 Mbit host sends a bunch of oversized packets in a short  
time because a number of TCP sessions are searching for the MTU and  
this happens on an old 10 Mbps network where this leads to some kind  
of exception state with further negative impact. (Hubs/switches that  
disconnect ports with too many errors, that kind of thing.)

Another difference is that in my draft, routers can announce a TCP  
MSS value but the MTU discovery overrides this information on the  
local subnet, which makes it easy to stick to 1500 byte (or smaller)  
packets across the net but use larger packets locally. Routers can  
also announce a maximum allowed MTU so it's easy to make sure that  
hosts don't send packets larger than a certain size administratively  
if desired. Obviously it's also possible to simply announce the  
largest possible MSS so large packets can be used across the internet  
(I think this may have been unclear this afternoon).

Last but not least, the RFC 4821 mechanism must be implemented per  
transport protocol, while the mechanism in my draft works at the IP  
layer so it doesn't introduce new logic in transports.

The idea of having switches send "too big" messages isn't very  
attractive for three reasons:

1. This isn't very robust at the IP layer with traditional PMTUD
2. A node could send packets that are so large that the switch can't  
receive them so it's not possible to send an ICMP message back either
3. Nodes would need to know whether the switches support this before  
they can send larger packets, which is more or less the same reason  
why most subnets aren't configured for jumboframes today

First reaction to issues with neighbor discovery over tunnels:  
tunnels have problems with MTUs in general and PMTUD in particular.  
There are many opportunities for problems, but I think in practice  
the mechanism I proposed wouldn't lead to much additional trouble  
because the MTU for the tunnel interface is generally low enough that  
the mechanism isn't used anyway, and probing + neighbor  
unreachability detection (for IPv6) will make sure it's possible to  
avoid problems and/or recover from them.

Multiple paths with multiple MTUs: you can't have loops in your  
ethernet topology, so the only way to do this is with 802.3ad link  
aggregation. As far as I can tell, at least some Cisco equipment  
makes sure bundled links all use the same MTU. Not sure if 802.3ad  
says anything about this. Also, switches don't send packets belonging  
to the same session over different links in a bundle to avoid packet  
reordering. So if an MTU failure occurs, it will be consistent.  
Because the actual traffic and the ICMP probe message aren't  
necessarily the same "session" it's possible that MTU probes and data  
traffic see different MTUs. Neighbor unreachability detection will  
have to detect the problem so the neighbor MTU is reset.

About 9000 bytes is not enough: all MTU fields are 32 bits in the  
draft.  :-)

Someone made me aware of this:

http://grouper.ieee.org/groups/802/3/frame_study/index.html

This effort doesn't increase the payload size of ethernet packets,  
though.

My conclusion:

Wide scale implementation of RFC 4821 makes the MTU probing packets  
unnecessary, but this and the other options and messages can still be  
useful for severa reasons:

- skip probing steps because neighbor MTU is known immediately
- allow administrators to limit MTU sizes
- use different MTUs for different link speeds for jitter/delay  
control and interaction with nodes/switches with limited capabilities
- allow unmodified transports to use larger packets

I'm thinking that it's probably possible and desireable to make all  
messages and options optional, with the exception of something that  
allows administrators to limit the MTU subnet-wide with one setting.  
But maybe cases can be made for completely removing some messages or  
options because it's unlikely they'll be implemented or provide many  
benefits if implemented. However, please note that although the  
number of new options and messages may seem a bit high, the way in  
which they work is actually very straightforward with very simple  
decision making logic and only a single new timer introduced.

The goal is to allow the use of larger packets between supporting  
nodes on a subnet. Whatever gets that done without breaking any old  
stuff that's reasonably still in use is fine by me.
Bob Briscoe | 24 Jul 03:09 2007
Picon

Re-ECN ad hoc BoF mentioned by Mark Handley (DoS-related)

Folks,

In Mark Handley's talk on what the IETF should do about DDoS in Int-AREA just now, he mentioned an ad hoc BoF on re-ECN.

The invite and proposed agenda is below. Note, the second hour will be a re-run of the general presentation on what the architectural intent is (from Prague IETF), for those that missed it.


Bob


Date: Tue, 17 Jul 2007 13:38:13 +0100
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Re-ECN meeting in Chicago
Thread-Index: AcfIb1dcZj34MKodRHiY9C/kzgz8ww==
From: <toby.moncaster <at> bt.com>
To: <re-ecn <at> ietf.org>
X-OriginalArrivalTime: 17 Jul 2007 12:38:03.0374 (UTC)
        FILETIME=[5144D8E0:01C7C86F]
X-Spam-Score: 0.131 () HTML_50_60,HTML_MESSAGE
X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1
Cc: tsv-area <at> ietf.org, tsvwg <at> ietf.org
Subject: [re-ECN] Re-ECN meeting in Chicago
X-BeenThere: re-ecn <at> ietf.org
X-Mailman-Version: 2.1.5
Reply-To: re-ecn <at> ietf.org
List-Id: re-inserted explicit congestion notification <re-ecn.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/re-ecn>,
        <mailto:re-ecn-request <at> ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/re-ecn>
List-Post: <mailto:re-ecn <at> ietf.org>
List-Help: <mailto:re-ecn-request <at> ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/re-ecn>,
        <mailto:re-ecn-request <at> ietf.org?subject=subscribe>
X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158

Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
        boundary="----_=_NextPart_001_01C7C86F.50BE3E6A"


All,

There will be another re-ECN unofficial "Bar BoF" happening at IETF69 in Chicago next Wednesday July 25th. It will be at 1300-1500 in the Red Lacquar room. This is a follow on to the meeting held in Prague in March (slides and notes for which can be found at <http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/refb/#Presentations>)

The aim of the meeting will be to discuss the next steps that need to be taken to move re-ECN forward. The draft agenda is as follows. If anyone would like to add any items please contact me on or off list.

5 mins          Administrivia
25 mins         presentation and discussion on encoding in IP v4 and v6 (rationale behind current choices,
                alternatives, etc)
10 mins         How to deploy experimentally (open mic)
10 mins         Deployment Scenarios
10 mins         Next Steps:
                   - format of the encoding (in v4, in v6)
                   - mechanics of the protocol in TCP/IP
                   - implementation of the dropper and the policer
                   - extension for use by TCP proxies or other congestion control proxies  
                   - extension for use by other transports
                   - etc

For those that missed it, we could use the second hour of the session to do a repeat of the presentation given in Prague in March. This was intended to present the architectural intent behind re-ECN as well as explaining how the base protocol works.

All Internet drafts and other documentation relevant to re-ECN can be found at: <http://www.cs.ucl.ac.uk/staff/B.Briscoe/projects/refb/> including draft-briscoe-tsvwg-re-ecn-tcp which describes the protocol and the rationale behind it.

Please could you address any replies to this message to the unofficial IETF mailing list re-ecn <at> ietf.org.

Toby Moncaster
____________________________________________________________________________
Toby Moncaster, <toby.moncaster <at> bt.com> Networks Research Centre, BT Research
B54/70 Adastral Park, Martlesham Heath, Ipswich, IP53RE, UK.  +44 1473 648734
_______________________________________________
re-ECN mailing list
re-ECN <at> ietf.org
https://www1.ietf.org/mailman/listinfo/re-ecn

____________________________________________________________________________
Bob Briscoe, <bob.briscoe <at> bt.com>      Networks Research Centre, BT Research
B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK.    +44 1473 645196
_______________________________________________
Int-area mailing list
Int-area <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area

Gmane