Brian Haberman | 2 Mar 15:32 2009
Picon

6MAN WG Last Call:draft-ietf-6man-overlap-fragment-01.txt

All,
      This message starts a 2-week 6MAN Working Group Last Call on 
advancing:

         Title     : Handling of overlapping IPv6 fragments
         Author(s) : S. Krishnan
         Filename  : draft-ietf-6man-overlap-fragment-01.txt
         Pages     : 7
         Date      : 2008-11-4

as a Proposed Standard.  Substantive comments and statements of support 
for advancing this document should be directed to the mailing list. 
Editorial suggestions can be sent to the document editor.  This last 
call will end on March 16, 2009.

Regards,
Brian & Bob
6MAN co-chairs
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Rémi Denis-Courmont | 2 Mar 16:16 2009
Picon

Re: 6MAN WG Last Call:draft-ietf-6man-overlap-fragment-01.txt


On Mon, 02 Mar 2009 09:32:33 -0500, Brian Haberman
<brian <at> innovationslab.net> wrote:
> All,
>       This message starts a 2-week 6MAN Working Group Last Call on
> advancing:
> 
>          Title     : Handling of overlapping IPv6 fragments
>          Author(s) : S. Krishnan
>          Filename  : draft-ietf-6man-overlap-fragment-01.txt
>          Pages     : 7
>          Date      : 2008-11-4
> 
> as a Proposed Standard.  Substantive comments and statements of support
> for advancing this document should be directed to the mailing list.
> Editorial suggestions can be sent to the document editor.  This last
> call will end on March 16, 2009.

Overall, I think this document should go forward.

However, the recommendation part should perhaps be a bit more explicit. I
assume the recipient node should not trash packets with a matching source,
destination and fragment ID *forever*, but rather within a reasonable time
frame.

--

-- 
Rémi Denis-Courmont

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

Suresh Krishnan | 3 Mar 16:13 2009
Picon

Issues from -07 resolved (was Re: draft-stjohns-sipso-*)

Hi Folks,
   The issues I raised on version 07 of this draft have been fixed in 
version 09 of the draft.

Cheers
Suresh

On 11/02/09 06:46 PM, Suresh Krishnan wrote:
> Hi Ran,
>   Very interesting read. I just had a couple of comments.
> 
> Section 5.1 : Option format
> 
> The alignment requirement for this option should be 4n+2 and not 4n as 
> mentioned in the document. This is required to align the CALIPSO DOI on 
> its natural 32 bit boundary.
> 
> Section 5.1.7 : CALIPSO Checksum
> 
> I do not see the real need for this option. I see two cases where the 
> calipso option will be secured
> 
> AH is present -> AH will detect the tampering as it covers the CALIPSO 
> option
> 
> AH is not present -> Attacker can tamper with the option and then 
> recalculate the checkum and insert in the option
> 
> Section 9.2 IANA considerations
> 
(Continue reading)

Ed Jankiewicz | 3 Mar 16:13 2009

Sad news

Word is out that Jim Bound passed away yesterday.  I don't know any 
other details, but thought that colleagues on these lists would want to 
know.

Jim could be brutally honest, but he was just as quick and generous in 
support of people and ideas he believed in as he was in criticizing what 
he recognized as wrongheaded or counterproductive.  I feel very
fortunate to have had his support in my work almost from the first day I 
surfaced in the IPv6 space.

--

-- 
Ed Jankiewicz - SRI International
Fort Monmouth Branch Office - IPv6 Research 
Supporting DISA Standards Engineering Branch
732-389-1003 or  ed.jankiewicz <at> sri.com 

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6 <at> ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Lars Eggert | 5 Mar 12:30 2009
Picon

fundamental concerns about draft-stjohns-sipso

Hi,

I'm currently holding a discuss on draft-stjohns-sipso, because I  
fundamentally question if this is a document the IETF should publish.  
The discuss is not actionable, i.e., I don't see any way to "fix" the  
document, so I'm deliberating what to do. I'd appreciate your thoughts  
on this situation.

In short, draft-stjohns-sipso asks for an IPv6 hop-by-hop option  
number for use in Multi-Level Security (MLS) networking environments,  
i.e., mostly governmental and military networks that use IP technology  
but are not "the Internet". MLS networking is standardized outside the  
IETF, and (in my opinion) diverges significantly from the Internet  
architecture, to the point where IETF transport and application  
protocols cannot generally be used on an MLS network without changes,  
or without trusted proxies that translate protocol flavors.

Should the IETF allocate option numbers for extensions to our  
fundamental protocols (in this case, IPv6) that are targeted solely at  
private walled-garden networks? Note that in addition to draft-stjohns- 
sipso, we have been receiving liaison statements from the ITU-T, which  
would also like an IPv6 hop-by-hop option number for their walled  
garden, so our decision on draft-stjohns-sipso might set a precedent.

A secondary concern is that this document resurrects IPv4 technology  
that has been declared Historic for continued use with IPv6, and in  
the meantime, the IETF has designed better protocol mechanisms that  
would arguably address the same set of requirements (for example,  
L3VPN). I understand the argument that the MLS architecture  
specifications require this sort of approach, but the ITU-T  
(Continue reading)

RJ Atkinson | 5 Mar 16:07 2009

Re: fundamental concerns about draft-stjohns-sipso


On  5 Mar 2009, at 06:30, Lars Eggert wrote:
> Should the IETF allocate option numbers for extensions to our  
> fundamental protocols (in this case, IPv6) that are targeted solely  
> at private walled-garden networks? Note that in addition to draft- 
> stjohns-sipso, we have been receiving liaison statements from the  
> ITU-T, which would also like an IPv6 hop-by-hop option number for  
> their walled garden, so our decision on draft-stjohns-sipso might  
> set a precedent.

All,

No.  That concern is misplaced.

The precedent that might be created is quite different,
and ought not be controversial, namely:

* As the standards body for IPv6, the IETF will consider and review
   proposals for IPv6 extensions (e.g. additional IPv6 options).

Approving this as an Informational RFC would NOT set a precedent
that the IETF would approve all such proposals for IPv6 extensions.
As all IPv6 options necessarily have different semantics and syntax,
the IETF community might well reach quite different (e.g. opposite)
conclusions about one proposal versus some other proposal.

If the IETF is the standards body for all IPv6 uses and extensions,
as it claims to be, it would be quite odd to refuse to consider
such IPv6-related proposals.

(Continue reading)

Lars Eggert | 5 Mar 18:37 2009
Picon

Re: fundamental concerns about draft-stjohns-sipso

Hi, Ran,

thanks for the timely response.

On 2009-3-5, at 16:07, RJ Atkinson wrote:
> On  5 Mar 2009, at 06:30, Lars Eggert wrote:
>> Should the IETF allocate option numbers for extensions to our
>> fundamental protocols (in this case, IPv6) that are targeted solely
>> at private walled-garden networks? Note that in addition to draft-
>> stjohns-sipso, we have been receiving liaison statements from the
>> ITU-T, which would also like an IPv6 hop-by-hop option number for
>> their walled garden, so our decision on draft-stjohns-sipso might
>> set a precedent.
>
> All,
>
> No.  That concern is misplaced.
>
> The precedent that might be created is quite different,
> and ought not be controversial, namely:
>
> * As the standards body for IPv6, the IETF will consider and review
>   proposals for IPv6 extensions (e.g. additional IPv6 options).

We have been considering and reviewing the proposal. But not all  
proposals end up getting approved.

> Approving this as an Informational RFC would NOT set a precedent
> that the IETF would approve all such proposals for IPv6 extensions.
> As all IPv6 options necessarily have different semantics and syntax,
(Continue reading)

Suresh Krishnan | 5 Mar 22:32 2009
Picon

Re: 6MAN WG Last Call:draft-ietf-6man-overlap-fragment-01.txt

Hi Remi,
   Thanks you for catching this.

On 02/03/09 10:16 AM, Rémi Denis-Courmont wrote:

> Overall, I think this document should go forward.

Great.

> 
> However, the recommendation part should perhaps be a bit more explicit. I
> assume the recipient node should not trash packets with a matching source,
> destination and fragment ID *forever*, but rather within a reasonable time
> frame.

Yes. You are right. The text in the draft is misleading. After further 
thought I felt that this text was extraneous anyway and can be safely 
removed. So, I propose the following change to this section.

OLD:
  IPv6 nodes that receive a fragment
    that overlaps with a previously received fragment MUST cease the
    reassembly process and MUST ignore further fragments with the same
    IPv6 Source Address, IPv6 Destination Address and Fragment
    Identification.  It MUST also discard the previously received
    fragments with the same IPv6 Source Address, IPv6 Destination Address
    and Fragment Identification.

NEW:
  IPv6 nodes that receive a fragment
(Continue reading)

RJ Atkinson | 6 Mar 17:50 2009

Re: fundamental concerns about draft-stjohns-sipso


On  5 Mar 2009, at 12:37, Lars Eggert wrote:
> It would not set a precedent that the IETF is approving *all*
> such proposals, but it would set the precedent that the IETF
> has approved *one* such proposal.

Please forgive me, but I disagree that the above is
a well formed concern.

Permitting one proposal to move forward as Informational has
NEVER implied that some different proposal needs to be approved
as either Informational or standards-track.

There is A LOT of IESG/IETF/WG history of approving one thing
and not approving another, for a wide range of protocols
in a variety of different IETF Areas for many many years now.

> At that point, we're arguing about whether IPv6 options
> for one kind of walled garden vs. another kind of walled garden are  
> OK.

I do not agree with this.

In particular, I don't think it is either accurate or descriptive
to call "MLS networking" a walled garden.  I agree it has significant
differences from the global Internet, but those differences are
fundamentally due to differences between any single-level OS
and any multi-level OS.

> My personal opinion is that "profiling" (to use an ITU-T term)
(Continue reading)

Internet-Drafts | 6 Mar 23:00 2009
Picon

I-D Action:draft-ietf-6man-ipv6-subnet-model-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Maintenance Working Group of the IETF.

	Title           : IPv6 Subnet Model: the Relationship between Links and Subnet Prefixes
	Author(s)       : H. Singh, et al.
	Filename        : draft-ietf-6man-ipv6-subnet-model-03.txt
	Pages           : 11
	Date            : 2009-03-06

IPv6 specifies a model of a subnet that is different than the IPv4
subnet model.  The subtlety of the differences has resulted in
incorrect implementations that do not interoperate.  This document
spells out the most important difference; that an IPv6 address isn't
automatically associated with an IPv6 on-link prefix.  This document
also updates (partially due to security concerns caused by incorrect
implementations) a part of the definition of on-link from [RFC4861].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-6man-ipv6-subnet-model-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--------------------------------------------------------------------
(Continue reading)


Gmane