[Softwires] Softwires WG meeting Notes

["Durand, Alain" <[e-mail]>]

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)" <[e-mail]>
Date: Wed, 29 Jul 2009 09:56:07 -0400
To: Alain Durand <[e-mail]>, David Ward
<[e-mail]>
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