Subject: Proposed agenda for IPv6 Operations - IETF 77

From: Fred Baker <[email-masked]>
Date: Tue, 16 Mar 2010 17:06:03 -0400

Comments please... Basically I am putting three security issues and two 3GPP-relevant drafts on Monday morning and the remainder on Friday morning. Each discussion gets about half an hour. If time permits in the meeting, I'll pull agenda items forward from Friday to Monday. I have two drafts on here that were not marked for v6ops but the authors asked me to include; next time I'd appreciate it if folks used the draft-*-v6ops-* naming convention; it makes my job easier. If I have missed anything, let me know.
IPv6 Operations - IETF 77

Monday 22 March, 9:00 AM
Agenda bashing
 
Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service
18-Feb-10, <draft-ietf-v6ops-cpe-simple-security-09.txt>
Advanced Security for IPv6 CPE
8-Mar-10, <draft-vyncke-advanced-ipv6-security-01.txt>
Routing Loops using ISATAP and 6to4: Problem Statement and Proposed Solutions
1-Feb-10, <draft-nakibly-v6ops-tunnel-loops-01.txt>

IPv6 in 3GPP Evolved Packet System
24-Feb-10, <draft-korhonen-v6ops-3gpp-eps-01.txt>
Mobile Networks Considerations for IPv6 Deployment
8-Mar-10, <draft-koodli-ipv6-in-mobile-networks-01.txt>
Friday 26 March, 9:00 AM
Emerging Service Provider Scenarios for IPv6 Deployment
23-Feb-10, <draft-carpenter-v6ops-isp-scenarios-01.txt>
Unicast Transmission of IPv6 Multicast Messages on Link-layer
15-Feb-10, <draft-gundavelli-v6ops-l2-unicast-00.txt>
Neighbor Cache Protection in Neighbor Discovery Protocol
2-Mar-10, <draft-jiang-v6ops-nc-protection-01.txt>
DHCPv6 Prefix Delegation as IPv6 Migration Tool in Cellular Networks
16-Feb-10, <draft-sarikaya-v6ops-prefix-delegation-00.txt>
Advanced Requirements for IPv6 Customer Edge Routers
8-Mar-10, <draft-wbeebee-v6ops-ipv6-cpe-router-bis-02.txt>

http://www.ipinc.net/IPv4.GIF

---

From: Naoki Matsuhira <[email-masked]>
Date: Wed, 17 Mar 2010 13:20:24 +0900

Fred,

I would like to present "Stateless automatic IPv4 over IPv6 Tunneling 
(SA46T) draft. Could you add this to the agenda ?

http://www.ietf.org/id/draft-matsuhira-sa46t-spec-00.txt
http://www.ietf.org/id/draft-matsuhira-sa46t-gaddr-00.txt

After submit these drafts, there are many positive reaction from the 
community in Japan. I believe this technology contribute to the 
Internet. Ten minutes are appropriate.

These draft does not use *-v6ops-* naming convention.  I apologizes to 
complex. Next update, I will change those.

Naoki.

Fred Baker wrote:
> 
> Comments please... Basically I am putting three security issues and two 
> 3GPP-relevant drafts on Monday morning and the remainder on Friday 
> morning. Each discussion gets about half an hour. If time permits in the 
> meeting, I'll pull agenda items forward from Friday to Monday. I have 
> two drafts on here that were not marked for v6ops but the authors asked 
> me to include; next time I'd appreciate it if folks used the 
> draft-*-v6ops-* naming convention; it makes my job easier. If I have 
> missed anything, let me know.
> 
> 
> *Agenda bashing*
> *Recommended Simple Security Capabilities in Customer Premises Equipment 
> for Providing Residential IPv6 Internet Service* 
> <http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security>
> *Advanced Security for IPv6 CPE* 
> <http://tools.ietf.org/html/draft-vyncke-advanced-ipv6-security>
> *Routing Loops using ISATAP and 6to4: Problem Statement and Proposed 
> Solutions* <http://tools.ietf.org/html/draft-nakibly-v6ops-tunnel-loops>
> *IPv6 in 3GPP Evolved Packet System* 
> <http://tools.ietf.org/html/draft-korhonen-v6ops-3gpp-eps>
> *Mobile Networks Considerations for IPv6 Deployment* 
> <http://tools.ietf.org/html/draft-koodli-ipv6-in-mobile-networks>
> *Emerging Service Provider Scenarios for IPv6 Deployment* 
> <http://tools.ietf.org/html/draft-carpenter-v6ops-isp-scenarios>
> *Unicast Transmission of IPv6 Multicast Messages on Link-layer* 
> <http://tools.ietf.org/html/draft-gundavelli-v6ops-l2-unicast>
> *Neighbor Cache Protection in Neighbor Discovery Protocol* 
> <http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection>
> *DHCPv6 Prefix Delegation as IPv6 Migration Tool in Cellular Networks* 
> <http://tools.ietf.org/html/draft-sarikaya-v6ops-prefix-delegation>
> *Advanced Requirements for IPv6 Customer Edge Routers* 
> <http://tools.ietf.org/html/draft-wbeebee-v6ops-ipv6-cpe-router-bis>

---

From: "Templin, Fred L" <[email-masked]>
Date: Sat, 20 Mar 2010 02:31:22 -0700

Fred,

The new agenda posted on the webpages does not seem to match the one
you posted to the list:

  http://www.ietf.org/proceedings/10mar/agenda/v6ops.html

Seeing that there are new additions, I would like to propose to add the
RANGER, VET and SEAL trilogy - preferably as the final session on
Friday, as I have two other conflicts for the earlier portion of that session.
The talk would require 15min, and would cover all three documents
together (i.e., not as three separate talks). The documents are here:

  http://www.ietf.org/rfc/rfc5720.txt
  http://tools.ietf.org/html/draft-templin-intarea-vet
  http://tools.ietf.org/html/draft-templin-intarea-seal

Thanks - Fred
[email-masked]

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Fred Baker
Sent: Tuesday, March 16, 2010 2:06 PM
To: IPv6 Operations
Subject: Proposed agenda for IPv6 Operations - IETF 77

Recommended Simple Security Capabilities in Customer Premises Equipment for Providing Residential IPv6 Internet Service<http://tools.ietf.org/html/draft-ietf-v6ops-cpe-simple-security>
18-Feb-10, <draft-ietf-v6ops-cpe-simple-security-09.txt>
Advanced Security for IPv6 CPE<http://tools.ietf.org/html/draft-vyncke-advanced-ipv6-security>
8-Mar-10, <draft-vyncke-advanced-ipv6-security-01.txt>
Routing Loops using ISATAP and 6to4: Problem Statement and Proposed Solutions<http://tools.ietf.org/html/draft-nakibly-v6ops-tunnel-loops>
1-Feb-10, <draft-nakibly-v6ops-tunnel-loops-01.txt>

IPv6 in 3GPP Evolved Packet System<http://tools.ietf.org/html/draft-korhonen-v6ops-3gpp-eps>
24-Feb-10, <draft-korhonen-v6ops-3gpp-eps-01.txt>
Mobile Networks Considerations for IPv6 Deployment<http://tools.ietf.org/html/draft-koodli-ipv6-in-mobile-networks>
8-Mar-10, <draft-koodli-ipv6-in-mobile-networks-01.txt>
Friday 26 March, 9:00 AM
Emerging Service Provider Scenarios for IPv6 Deployment<http://tools.ietf.org/html/draft-carpenter-v6ops-isp-scenarios>
23-Feb-10, <draft-carpenter-v6ops-isp-scenarios-01.txt>
Unicast Transmission of IPv6 Multicast Messages on Link-layer<http://tools.ietf.org/html/draft-gundavelli-v6ops-l2-unicast>
15-Feb-10, <draft-gundavelli-v6ops-l2-unicast-00.txt>
Neighbor Cache Protection in Neighbor Discovery Protocol<http://tools.ietf.org/html/draft-jiang-v6ops-nc-protection>
2-Mar-10, <draft-jiang-v6ops-nc-protection-01.txt>
DHCPv6 Prefix Delegation as IPv6 Migration Tool in Cellular Networks<http://tools.ietf.org/html/draft-sarikaya-v6ops-prefix-delegation>
16-Feb-10, <draft-sarikaya-v6ops-prefix-delegation-00.txt>
Advanced Requirements for IPv6 Customer Edge Routers<http://tools.ietf.org/html/draft-wbeebee-v6ops-ipv6-cpe-router-bis>
8-Mar-10, <draft-wbeebee-v6ops-ipv6-cpe-router-bis-02.txt>

---

From: Fred Baker <[email-masked]>
Date: Sat, 20 Mar 2010 09:15:41 -0700

Well, yes. the one I posted to the list was entitled a "proposed" agenda, and I got several notes after that from people who had not put the word "v6ops" in their draft monikers asking to be added to it. That's why I later posted that people could look at the posted agenda.

Before I add these, let me ask: are they being discussed in int-area? If not, I'll add the slot Friday as requested.

On Mar 20, 2010, at 2:31 AM, Templin, Fred L wrote:

> RANGER, VET and SEAL trilogy – preferably as the final session on
> Thanks – Fred

---

From: Fred Baker <[email-masked]>
Date: Sat, 20 Mar 2010 22:27:47 -0700

I have a question on these.

Per the abstract of VET, "VET can also be considered as version 2 of the Intra-Site Automatic Tunnel Addressing Protocol (i.e., "ISATAPv2")." I tend to agree; with routing, next hop determination, and a "Subnetwork Encapsulation and Adaptation Layer (SEAL)", I don't think this is an operational description. I think this belongs discussed in rrg, rtgarea/rtgwg, or *maybe* int-area.

How about you and I discuss this Monday and you convince me that this is within the charter of IPv6 Operations. I think it is that which was explicitly placed outside the charter - transitional technologies and protocol development.

---

From: "Templin, Fred L" <[email-masked]>
Date: Sun, 21 Mar 2010 07:02:44 -0700

Fred,

As far as I can tell, the SAM proposal is a new transitional
technology and protocol also. RANGER and SAM are addressing
very similar problem spaces, and I think their eligibility
for inclusion in the v6ops agenda should be considered on
equal terms.

Thanks - Fred

> -----Original Message-----
> From: Fred Baker [mailto:[email-masked]]
> Sent: Saturday, March 20, 2010 10:28 PM
> To: Templin, Fred L
> Cc: IPv6 Operations; Ron Bonica; Kurt Erik Lindqvist
> Subject: Re: Proposed agenda for IPv6 Operations - IETF 77
> 
> Per the abstract of VET, "VET can also be considered as version 2 of the Intra-Site Automatic Tunnel
> Addressing Protocol (i.e., "ISATAPv2")." I tend to agree; with routing, next hop determination, and a
> "Subnetwork Encapsulation and Adaptation Layer (SEAL)", I don't think this is an operational
> description. I think this belongs discussed in rrg, rtgarea/rtgwg, or *maybe* int-area.
> 
> How about you and I discuss this Monday and you convince me that this is within the charter of IPv6
> Operations. I think it is that which was explicitly placed outside the charter - transitional
> technologies and protocol development.
> 
> 
> > Comments please... Basically I am putting three security issues and two 3GPP-relevant drafts on
> Monday morning and the remainder on Friday morning. Each discussion gets about half an hour. If time
> permits in the meeting, I'll pull agenda items forward from Friday to Monday. I have two drafts on
> here that were not marked for v6ops but the authors asked me to include; next time I'd appreciate it
> if folks used the draft-*-v6ops-* naming convention; it makes my job easier. If I have missed
> anything, let me know.

---

From: Rémi Després <[email-masked]>
Date: Sun, 21 Mar 2010 11:02:42 -0700

Fred,

On February 19, I wrote on to Fred, with copy to the v6ops list:
<<<
Draft-despres-softwire-sam-00, which I will post in a few days, contains an updated description of SAM, the generic Stateless Address Mapping mechanism which applies to a variety of scenarios.

Among those, one permits ISPs to deliver native IPv6 connectivity across legacy CPEs that only support NAT44 with port forwarding.
This solution is like 6rd in that:
- ISPs don't need to change their IPv4 infrastructures
- They only need to operate gateways between these and their IPv6 accesses
- These gateways are stateless
It is unlike 6rd in that:
- Legacy CPEs don't need to be upgraded
- To exploit of their IPv6 addresses, hosts have to be upgraded to support SAM.

Operation considerations of this scenario are relevant to v6ops.
A time slot for a presentation will be appreciated.

Although the agenda of v6ops doesn't specify it, what I will present on friday is very far from a general SAM presentation like the one I asked to have in Softwire, but couldn't be scheduled due to the lack of enough time allocated to Softwire.

As initially planned, my presentation will be limited to the "Native IPv6 across NAT44s" scenario.

Regards,
RD

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 22 Mar 2010 07:28:11 -0700

Remi,

>From what I could tell, even for the NAT44 case you are
describing there is still a need for host modifications.
Also a need for DHCP server modifications, and a new
type of router in provider networks. That makes SAM a
new transition technology and a new protocol.

Fred

> From: Rémi Després [mailto:[email-masked]]
> Sent: Sunday, March 21, 2010 11:03 AM
> To: Templin, Fred L
> Cc: Fred Baker; IPv6 Operations; Ron Bonica; Kurt Erik Lindqvist
> Draft-despres-softwire-sam-00, which I will post in a few days, contains an updated description of
> SAM, the generic Stateless Address Mapping mechanism which applies to a variety of scenarios.
> 
> Although the agenda of v6ops doesn't specify it, what I will present on friday is very far from a
> general SAM presentation like the one I asked to have in Softwire, but couldn't be scheduled due to
> the lack of enough time allocated to Softwire.
>