[Softwires] Softwires WG meeting Notes

["Durand, Alain" <Alain_Durand at cable.comcast.com>]

Title: Softwires WG meeting Notes

Here is a preview of the meeting minutes, please send any update/change to me asap before I sent this to the secretariat.

  - Alain.

------ Forwarded Message
From: "Chris Metz (chmetz)" <chmetz at cisco.com>
Date: Wed, 29 Jul 2009 09:56:07 -0400
To: Alain Durand <Alain_Durand at cable.comcast.com>, David Ward <dward at cisco.com>
Subject: Softwires WG meeting Notes

Softwires WG Meeting
IETF75, Stockholm
July 29, 2009
 
Chairs: David Ward, Alain Durand
 
Minutes Follow
 
Chairs opened with Introduction, a small agenda-reorder action and the “note-well. David remarked that Softwires Mesh is RFC5565.
 
draft-cui-softwire-va-based-softwire-00  – Yong Cui
-         Discussed main points of draft. E-IP prefixes aggregated into Virtual Prefixes (VP) and stored in core APR routers. Softwire tunnels established between edge routers and APR routers. Primary objective is shrink FIB size on AFBR routers

-         Send comments to mailing list

 
draft-cui-softwire-pet-00 - Yong Cui
-         IPv4/IPv6 Coexistence Framework Prefixing/Encap/Translation (PET)PET Framework Draft

-         Issue: many tunneling and translation methods for IPv6 transition. Lots of boxes in network capable of doing both

-         Question: Do we need methods for transition boxes to negotiate and signal their preferred transition capabilities amongst one another versus the alternative of operator doing it manually

-         Showed example of a Core AFT (address family translator) and then an Edge AFT reached across the core by a tunnel. Which is better?

-         Outlined PET framework

-         Showed table of different permutations with IPv6-only backbone

-         Send comments to mailing list

-         Alain: Discuss with behave chairs

 
 
Draft-ietf-softwire-dual-stack-lite-01 - Yui Lee
-         Summarized 00 – 01 diffs

-         Port Allocation – automatic or static (a+p with user-controlled alg, dynamic) or dynamic port reservation

-         Port Assignment – automatic, static via web interface, UPnP/nat-pmp dynamic port reservation

-         Discussed automatic method –  where CGN allocates

-         Discussed static port reservation method the 2 methods outlined in the draft

-         Discussed dynamic port reservation (application driven) – nat-pmp is better than upnp because it says “port X not avialble try port Y instead”, upnp expected to enhance function, also need to increase timeout so more time to get address from upstream CGN

-         Discussed MTU issue

-         CGN must wait for privateàpublic ds-lite fragments to arrive, buffer and then send – most packets sent from Internet where CGN forwards immediately rather than waiting

-         Suggest relaxation of  RFC2473 and fragment packet even though df bit set? If pMTU is broken

-         CGN security – 2 layers of acl – ipv6 outer and IPv4 (private, iana- a+p) inner

-         CGN security – web sites penalize after unsuccessful logon attempts, 

-         Fred Templin comment: look at SEAL  (RFC5520) to do frag/reassbl below IPv6 – working on draft-SEAL-bis draft

-         Dan Wing: BEHAVE discussed CGN issues – these are specific to all NATs, not just CGN found in ds-lite, recommend to discuss in ALAIN

-         Alain: IESG encouraged us to include CGN discussion in this draft

-         Magnus:  Fragmentation at one or both ends is problematic

-         Fred: Check out SEAL for recommendation on how to handle fragmentation/reassembly

-         Dave Thaler: 1) need informative reference to NAT security or just address sharing 2) delete suggestion of MSS messing, alternative is to explain issue with e2e security, not just specific tcp-ao

-         Anonymous: Layer violations and bizarness with changing TCP in layer above IP 

-         Fred: SEAL is a shim

-         Alain: Question on whether to remove fragmentation/mss discussion from document or keep it

-         Dward: remove it

 
draft-townsley-ipv6-6rd-01 - Mark Townsley
-         One slide rollup

-         6rd Prefix Delegation

-         IPv4 bits in 6rd IPv6 can be private – use only 24 bits and includes domain id if 1918 is overlapped

-         6rd RG implementation discussed and then showed encap/decap mappings in each direction

-         6rd BR provisioning

-         6rd CE provisioning – by dhcp, ppp icp, tr69

-         Proposed 6rd dhcp option 

-         Dave Thaler (DT): Does 6rd support CE learning of and using multiple BR simultaneously? We know that Teredo, ISATAP and 6to4 support.

-         Mark: No but could be added. What is Use case? 

-         DT: Ise multiple BR to get to different places or faster CE-triggered failover

-         DT: Can single host running 6rd receive RA from BR? 

-         MT: No but desire is to do minimal set to functions to deliver IPv6 connectivity

-         Alain: we have Softwire Hub/Spoke but 6rd is simpler

-         Fred: 6rd is a fusion of isatap/vet and 6to4, can do TE if CE is aware/uses multiple BR 

-         Dward: interest is working this? Approx 15 hands raised

-         Alain: Need to do charter tweaking and take to mailer

 
draft-thaler-behave-translator-addressing-00 – Dave Thaler
-         Presentation given in BEHAVE meeting yesterday

-         Open issue or question for softwire meeting is applicability of this draft to softwires efforts

-         Translatable is assigned to an IPv6 host; Mapped is assigned to a tunnel end-point

-         Called out prefix requirements

-         Address format requirements – checksum neutral if stateless not applicable to tunnel encap/decap case

-         Showed address formats and some are similar to tunnel encap/decap

-         Options to move forward are: nothing, combined doc, split normative/informative doc and …

-         Dui Chen: question on translation format from PNAT (discussed in BEHAVE meetings). Chair responded discussion around tunneling whereas BEHAVE handles translation

-         Anonymous: we should care

-         Remi: we should care

-         Prof. Li: support joint document

-         Alain: Asked if we should document in softwire WG - About 20 people raised their hands

 
Draft-dhankings-softwire-tunnel-option-03 – Shane Kerr
-         DHCP option for tunnel end-points

-         Brief list of items brought up on mailing list

-         Send comments to mailing list

 
Draft-guo-softwire-sc-discovery - Dayong Gao
-         Problem: need mechanism to discover ds-lite tunnel concentrator (TC)

-         Alain: this option and previous DHCPoption compatible? Gao: Answer is no

-         Alain: We should decide of we have one all-solution generic DHCP option or per-solution DHCP tunnel option

-         Ralph Droms: No longer constrained by number of DHCP option codes

-         Fred:  Observation of similarity with isatap potential router list

-         Remi: 6rd DHCP is short, compact with minimum information whereas in this solution we have a extra info that some solutions will not use

-         Gao: attempt to create generic framework/template to accommodate multiple solutions

-         Mark Townsley: Support separate DHCP options

-         Anonymous: why 3 different sc-types? Also questioning protocol type of v6 encapsulated in v6 tunnel, is there a use-case for this. Gao responded yes there could be use case.

-         Shane Kerr: Personnel preference for separate, per-solution DHCP options but this document could be useful as reference work

-         Ralph: Overhead of getting one option passed might obviate need to do this in the future for each new tunnel type

 
A+P – Randy Bush
-         It’s architecture complete; just wants one place to discuss

 
Stateless IPv4-IPv6 Interconnection DS-lite and A+P – Pierre Levis 
-         I-D.boucadair-behave-ipv6-portrange

-         I-D.boucadair-dslite-interco-v4v6

-         Outlined general solution where access network (inclusive of CPE and CGN/DS-Lite TC/PRR) and core are all IPv6. IPv6 ISP networks connected to IPv4 Internet by Interconnection Function (ICXF). CPE uses IPv4 to access public IPv4 Internet. So IPv4 packet in ds-lite tunnel to CGN, decapped and then mapped into special IPv4-mapped IPv6 address pointing to ICXF that receives packet decaps and sends on its way. BGP used by ICXF to advert IPv6 reachability to ICXF.  

-         Alain: Why is softwire mesh not applicable here?

-         Pierre: Need to analyze

-         Fred: can use ds-lite in 4over6over4 scenarios

-         Dward: need to clarify routing at peering point

-          

 
draft-sarikaya-softwire-dslitemobility-00 - Behcet Sarikaya
-         Question: does ds-l appy to mobility solutions

-         Requirements: mobility different, IPv4 hosts support MIPv4, qos

-         Mobility Solution #1 – ds-lite tunnel between PMIPv6 MAG and LMA

-         Mobility Solutoin #2 – ds-lite tunnel from MIPv4 host and combo HA/ds-l TC

-         Alain: Not much done with mobility in softwire. Check with Mobility WG

-         Mark Townsley: When chartered we excluded mobility because they have means to do MIPv4/v6

-         Raj Patel: nothing useful other than CGN in LMA

-         Ralph Droms: Review mobility WG to determine if this adds to MIP/PMIP methods

 
Meeting Adjourned
 


------ End of Forwarded Message