headers
Fred Baker | 1 Aug 2005 07:15
Picon
Favicon

v6ops agenda

At long last, the proposed agenda for today's meeting. We will bash  
this in the course of the meeting as well.

First, current document status:

         RFC Editor's queue:
          - draft-ietf-v6ops-3gpp-analysis-11.txt
          - draft-ietf-v6ops-renumbering-procedure-05.txt
          - draft-ietf-v6ops-mech-v2-07.txt
          - draft-huitema-v6ops-teredo-05.txt

         WG Last Call complete:
          - draft-ietf-v6ops-onlinkassumption-03.txt
          - draft-ietf-v6ops-natpt-to-exprmntl-01.txt
          - draft-ietf-v6ops-vlan-usage-00.txt
          - draft-ietf-v6ops-bb-deployment-scenarios-03.txt
          - draft-ietf-v6ops-security-overview-02.txt

         In discussion today with respect to WG last call comments:
          - draft-ietf-v6ops-nap-01.txt
          - draft-ietf-v6ops-ipsec-tunnels-00.txt
          - draft-ietf-v6ops-ent-analysis-03.txt

         New proposals:
          - draft-vives-v6ops-distributed-security-framework-00.txt
          - draft-davies-v6ops-icmpv6-filtering-bcp-00.txt

         I'm not sure where these are going:
          - draft-chown-v6ops-renumber-thinkabout-02.txt
          - draft-palet-v6ops-ipv6security-02.txt
(Continue reading)

Permalink | Reply | 2 comments |
headers
Gunter Van de Velde (gvandeve | 1 Aug 2005 09:13
Picon
Favicon

Re: v6ops agenda

<snip>
draft-vandevelde-v6ops-nap-01.txt
<end snip>

Replaced with draft-ietf-v6ops-nap-* drafts.

G/

At 07:15 1/08/2005 +0200, Fred Baker wrote:
>At long last, the proposed agenda for today's meeting. We will bash
>this in the course of the meeting as well.
>
>First, current document status:
>
>         RFC Editor's queue:
>          - draft-ietf-v6ops-3gpp-analysis-11.txt
>          - draft-ietf-v6ops-renumbering-procedure-05.txt
>          - draft-ietf-v6ops-mech-v2-07.txt
>          - draft-huitema-v6ops-teredo-05.txt
>
>         WG Last Call complete:
>          - draft-ietf-v6ops-onlinkassumption-03.txt
>          - draft-ietf-v6ops-natpt-to-exprmntl-01.txt
>          - draft-ietf-v6ops-vlan-usage-00.txt
>          - draft-ietf-v6ops-bb-deployment-scenarios-03.txt
>          - draft-ietf-v6ops-security-overview-02.txt
>
>         In discussion today with respect to WG last call comments:
>          - draft-ietf-v6ops-nap-01.txt
>          - draft-ietf-v6ops-ipsec-tunnels-00.txt
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Chown | 1 Aug 2005 09:17
Picon
Favicon

Re: v6ops agenda


On Mon, Aug 01, 2005 at 07:15:20AM +0200, Fred Baker wrote:
>
>         I'm not sure where these are going:
>          - draft-chown-v6ops-renumber-thinkabout-02.txt

This is now -03, and aims to be complementary to your renumbering
procedure text.  It will be updated again based on feedback from the
renumbering discussion today.

>          - draft-vandevelde-v6ops-nap-01.txt

That's now draft-ietf-v6ops-nap-01 and very much on track :)

Tim
Permalink | Reply | 0 comments |
headers
Fred Baker | 1 Aug 2005 17:54
Picon
Favicon

IETF63 Summary v6ops

v6ops is about to send you the following documents for AD review and  
eventual IESG movement. These have been through working group last  
call; I am completing the indicated paperlesswork.

     draft-ietf-v6ops-onlinkassumption         informational,  
corollary to draft-ietf-ipv6-2461bis-04.txt
     draft-ietf-v6ops-natpt-to-exprmntl
     draft-ietf-v6ops-vlan-usage

These documents will be last-called after the meeting and will likely  
be sent to you in September
     draft-ietf-v6ops-ipsec-tunnels
     draft-ietf-v6ops-ent-analysis
     draft-ietf-v6ops-nap
     draft-ietf-v6ops-security-overview

Waiting for Cable Labs input
     draft-ietf-v6ops-bb-deployment-scenarios

These are new work that v6ops will pick up
     draft-davies-v6ops-icmpv6-filtering-bcp - as a potential BCP
     draft-vives-v6ops-distributed-security-framework - potential BOF  
next meeting, in security area

We also had a presentation by Ralph Droms and a list of folks from  
6NET on the renumbering project that they did. There is some follow- 
on work, including a document publication sometime next year. The  
upshot of that is a variety of documents from Cisco and 6Net, and  
some specific recommendations to be posted to the mailing list. draft- 
chown-v6ops-renumber-thinkabout will be updated, and there may be
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fred Baker | 5 Aug 2005 07:08
Picon
Favicon

Last Call on draft-ietf-v6ops-security-overview-02.txt

With this note, I am opening a working group last call on draft-ietf- 
v6ops-security-overview-02.txt. This WGLC will close in two weeks, at  
close of business 19 July. Please read the document and comment to  
the list - either say that the document is ready, or say what issues  
you may have with it.

Thanks.
Permalink | Reply | 6 comments |
headers
Fred Baker | 5 Aug 2005 07:08
Picon
Favicon

last call on draft-ietf-v6ops-ipsec-tunnels-00.txt

With this note, I am opening a working group last call on draft-ietf- 
v6ops-ipsec-tunnels-00.txt. This WGLC will close in two weeks, at  
close of business 19 July. Please read the document and comment to  
the list - either say that the document is ready, or say what issues  
you may have with it.

Thanks.
Permalink | Reply | 0 comments |
headers
Fred Baker | 5 Aug 2005 07:08
Picon
Favicon

Last call on draft-ietf-v6ops-nap-01.txt

With this note, I am opening a working group last call on draft-ietf- 
v6ops-nap-01.txt. This WGLC will close in two weeks, at close of  
business 19 July. Please read the document and comment to the list -  
either say that the document is ready, or say what issues you may  
have with it.

Thanks.
Permalink | Reply | 3 comments |
headers
Fred Baker | 5 Aug 2005 07:08
Picon
Favicon

Last Call on draft-ietf-v6ops-ent-analysis-03.txt

With this note, I am opening a working group last call on draft-ietf- 
v6ops-ent-analysis-03.txt. This WGLC will close in two weeks, at  
close of business 19 July. Please read the document and comment to  
the list - either say that the document is ready, or say what issues  
you may have with it.

Thanks.
Permalink | Reply | 0 comments |
headers
Pekka Savola | 5 Aug 2005 21:47
Picon

WGLC ent-analysis-03: DSTM

Hi,

(I'll put two most separable & possibly most discussable items in 
separate mails.)

In 8.1:

  Later in the transition process, after the enterprise has
  transitioned to a predominately IPv6 infrastructure, the architect
  should implement the Dual-IP Transition Mechanism [DSTM, DSTM+]. Or
  in the case of early deployment of IPv6-dominant networks DSTM can
  be used too.

and in 8.4:

DSTM [DSTM, DSTM+] is a useful tunneling mechanism for later in the
enterprise transition or deployment of IPv6-dominant network links
is desired. DSTM is to being submitted as an IETF Experimental RFC.

==> as it is, DSTM is a way too overloaded a mechanism to be referred to
without more disclaimers or description.  As it is, different people use
"DSTM" to mean at least the following things:
  a) v4-in-v6 tunnels
  b) automatically set-up v4-in-v6 tunnels
  c) automatic set up of v4-in-v6 tunnels when the host
     doesn't have v4 address and an app wants to create a v4 socket
  d) automatic monitoring and tear-down of said v4-over-v6 tunnel
     when the host detects it no longer needs the address/connectivity
  e) plus a number of extensions for even more colorful setups.
(Continue reading)

Permalink | Reply | 22 comments |
headers
Pekka Savola | 5 Aug 2005 21:44
Picon

comments on draft-davies-v6ops-icmpv6-filtering-bcp-00.txt

I think the document is good and necessary one, but (IMHO) still (well, it's
a -00 version :) requires substantive work.  Note: I didn't look more than
about 5 pages or so, because the flight ended, but I think you get the
picture ;-)

1)

I think the most important issue is representation of the requirements and
summing them up.  That is, the recommendations should be categorized in
roughly following categories:

  * must not drop these messages (e.g., pkt too big)
  * should not drop these messages, think twice before you even consider it!
(most other ICMP errors)
  * these messages may be dropped but there's really no need to drop them
(redirects, ns/na, rs/ra, etc. -- things that the specifications say MUST be
discarded if they come from with hop count != 255 or link-local address
checks)
  * may or may not want to drop these
  * should consider dropping these messages (e.g., ICMP name lookups)

secondly, the messages/rules needed at the firewall to ensure its own
link-local messaging works OK should be separated from "transiting" messages
(split in categories like above).

further, the guidance needs to be summarized in some form: e.g., a table at
the end and/or very short pseudo-rules.

2) it may also already have come across above, but IMHO most of the
recommendations right now seem too strict and/or unnecessary.  I don't think
(Continue reading)

Permalink | Reply | 0 comments |

Gmane