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 

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:

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. 

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

_______________________________________________
Int-area mailing list
Int-area <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area

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

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

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

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.

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.

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

_______________________________________________
Int-area mailing list
Int-area <at> lists.ietf.org
https://www1.ietf.org/mailman/listinfo/int-area