IETF SOFTWIRE INTERIM
MEETING
Beijing,2011 September
26-27
===================================
Notetakers: Ole Troan, Ralph Droms,
Wojciech Dec
0900 - Introduction section
----------------------
Alain going through introduction
slides.
Agenda bashing:
Alain re agenda: random
order is for fairness.
Woj: It would make sense
to have operator input first.
Ole: Two ways of doing
it. Either apply logical structure first or deep dive first.
Ralph: Fine with the
order
Jari: Come here to do
divide & conquer. But the deep dive may give some learning. Analytical
part.
Agree, with Wojciech and Ole.
Hui: Do we have the motivation draft today?
Alain: No.
Background:
ID card(presented to assess each solution):
- NAT bindings
maintained on CPE, not CGN
- H&S vs Mesh
- Implicit or explicit
provisioning
- Address mapping rules
- Integration with
existing mechanism
Xing: Are they orthogonal. We need
to define some orthogonal axis.
Alain: Yes, we need that.
Woj: What do you mean by integration
with existing mechanism
Alain: Characteristic. How it
relates to things that already exist.
Woj: Two comments. The plugs are
there for a reason. The solution was the multiprotocol solution.
You
mentioned NAT was outside of scope. You declaring some element out of it?
Alain: No, we don't exclude dIVI,
but we don't want details on NAT64 or NAT46. or NAT444.
Jari: Talk about general aspects.
I'm worried about if we are doing one or multiple standards. It
would be far easier if we came up with one answer rather than multiple answers. It
isn't about filling all the space in the solution matrix.
This
is not just a technical discussion, we have to bridge it to the ISP
requirements. So from my perspective it should be backed in wide interest in SP
interest in that space.
Ralph: Agree with Jari, one solution
is easier to move forward with compared to multiple solutions. We have an
opportunity to avoid that.
Hope everyone will focus on understanding the common requirements. We
are doing this to meet operator requirements. We need to minimize the number of
solutions.
Woj: Fully agree. Quantifying the
operator interest. One can always speculate what operators want...
Xing: Agree
Ralph: To Woj. We have people in the
room that we can take a que from. And the working group. But there are other
interests. First hand accurate input.
Jari: A few other things. What do we
need to get the end? An RFC or set of RFCs on this technology.
Motivation document needs some more work.
Have to make selection / decisions on big topics. On Alains slides. Tunnel
versus translate. Or address mapping rules
There are other things too. I'm concerned to when dividing ports to customers,
it creates some inflexibility.
Changing the
allocation will be difficult. That should be looked at. Consequence of port
allocation.
Ralph: As we go through the discussion,
keep in mind that parts can be kept separate. e.g. mapping can be kept separate
and independent of "transport".
2. Deep Dive (7hours) - Chairs and presenters
-------------------------------------
Some discussion on the "deep
dive" agenda.
Alain, Woj, Hui, Yong
9:30-10:30 Xiaohong Deng
1. Architectural considerations of Stateless A+P
with a focus on SMAP
http://tools.ietf.org/html/draft-boucadair-behave-ipv6-portrange-04
Woj: ICXF: Are you showing that as a
translator?
Xiao: Yes, something like that. It
is doing encapsulating. PRD: encapsulating
Linjian: Q: What happens during with
the packet goes through the CGN. What changes after the CGN? What happens with
the IPv6 packet?
Xiao: Stateless address mapping. If
it goes to the outside internet (ICXF) or inside packet.
Alain: Send presentations!
Xing: Static port range with PRR,
dynamic tunneling
Jari: IPv6 routing doesn't take port
space into account.
Xiao: CPE is going to have the same
IPv6 prefix for stateful and stateless traffic.
Jari: I'm being slow this morning...
My issue is that when the port range change, then the IPv6 address change?
Xiao: It is impossible to not make
the IPV6 prefix length dependent on.
Satoru: Assigning the IPv6 prefix.
To avoid allocating the well known IPv4 address? Mapping rule encoding
Full
IPV4 address IPv6 operator has to avoid allocating IPv6 prefix that results in
well known IPv4 address?
Alain: The IPv6 address of the
customer is not related to the IPv4 address?
Remi: Independent of IPv6 and IPv4.
Includes the full IPv4 address in the IPv6 address.
Woj: Still struggling. DHCPv6
options.
Ole: Independent or dependent??
Explicit provisioning.
Roberta: Clarification about the
prefix. Either well known prefix, or a prefix from the service provider. Either
way.
Remi: Share understanding. The port
range is learnt from the IPv6 prefix. It has a prefix that includes an IPv4
address and a port mask.
Ralph: If there is an algorithmic
mapping, there is no need to have the IPv4 address in the DHCP option.
Alain: there are two different
things. one is the source address and one is the destination address.
my
understanding was that they use DHCP to give the address and port range, but to
find the IPv6 destination the algorithmic mapping.
Ole: Question on how IXF-IXF traffic is meant to happen
Xiao: Rules need to be applied on IXF.
2. DHCPv6 Options for Shared IP Addresses
Solutions
http://tools.ietf.org/html/draft-boucadair-dhcpv6-shared-address-option-00
Alain: Carrying IPv4 addresses in
IPv6 options?
Ralph: I don't think the DHC WH has
a formal opinion. The case of optimizing DHCP to carry both addresses in one
protocol in the DS case, they have stayed away from
Alain: 3 options. Carry DHCPv4 over
IPv6, DHCPv4 payload, or DHCPv6.
Alain: If the packets go through the
tunnel. It is an easier way to configure DHCP???
Ole: But you don't have IPv4
transport.
10:45-11:15 Peng Wu
DHCPv4 over IPv6
//http://datatracker.ietf.org/doc/draft-cui-softwire-dhcp-over-tunnel
draft-ietf-dhc-dhcpv4-over-ipv6-00
Presents address/port delegation method for stateful solutions(public
4over6).
DHCP tunnel vs. adaptation: apparent problems with dhcpv4 over
softwire tunnel highlighted by DHC WG - DHC would like it to be more generic,
applicable to any tunnel.
Jari: Why option 82, isn't the IPv6
the soruce address in the packet?
Peng: Not available for DHCP server
process. It is possible, but it is extra effort.
Remi: Is there a security issue
here? The packet has the real IPv6 address; if they are different from the
option 82.
Is
that an issue?
Peng: Not directly related to DHCP
Jari: There is, but how serious is
it.
Alain: Here we have two ways of
doing it. From Ralph what is the more generic.
Ralph: I don't follow why tunnel or
transport one is more generic or one is more specific?
There
are some details in the tunnel solution. the biggest issue that dhcpv4 assumes
that broadcast is available.
Alain: if it is a p2p tunnel, then
broadcast is simple.
Ralph: if you are saying that there
is a mechanism for... I'm not sure that the broadcast semantics map into the
IPv6 transport.
Ole: Need DHCP server discovery and
new DHCPv4 options for 4rd. This only applies to the DS-lite case.
Remi: Same point.
Peng: Agree.
Woj: Basic question. Intent of this
proposal, recreate a link-layer over IPv6. We just pass DHCPv4 over tunnel.
Alain: different properties
Woj: If we talk about port range,
then why not just define a new DHCPv4 option, just do it on IPv4.
What
are the requirements for this?
Alain: Will be covered later.
11:15-12:15 Naoki Matsuhira
Motivation for developing SA46T and SA46T-AS
http://tools.ietf.org/html/draft-matsuhira-sa46t-motivation-00
SA46T & SA46T-AS technology dive
http://tools.ietf.org/html/draft-matsuhira-sa46t-spec-02
http://tools.ietf.org/html/draft-matsuhira-sa46t-as-00
ISATAP for IPv6. Map full IPv4 address into IPv6.
Ole: Questions on:
-
import IPV4 routing into IPv6
-
host to host
-
separate IPv6 native network
-
provisioning
- what happens with local applications?
Xing: Address mapping rule. It is
different from local or Internet?
Alain: Related to H&S or mesh?
Xing: E.g. in translation case,
there is IPv4 translatable there is IPv4 converted address. Should use the same
prefix, but not necessary.
Alain: Adds row in ID card matrix to
identify different mapping rules.
--------------- 12:15-13:30 Lunch ---------------
13:30-14:00 Tetsuya Murakami
IPv4 Residual Deployment on IPv6 infrastructure
- protocol specification
http://tools.ietf.org/html/draft-murakami-softwire-4rd-00
4rd
specification
Jari, Alain: How does ICMP work?
Alain: How does IPsec work?
Jari: IPsec works with IPsec NAT
traversal in UDP encap.
Alain: Fragmentation?
Remi: Consequence of address sharing
Alain: A+P issues needs to be
clearly documented somewhere.
Remi: The first document of 4rd was
-sam.
Alain: Thanks.
14:00-14:30 Remi Despres
Stateless Address Mapping for IPv4 Residual
Deployment (4rd)
http://tools.ietf.org/html/draft-despres-softwire-4rd-addmapping-00
4rd b1/b2
Decoupled from encap or translation. Allows both.
4rd a,b, b1, b2 - changes to algorithm and mapping
Well known OUI based IID for mapped address representation
Jari: I wanted more IPv6 space, but
we can't do that unless we also give IPv4 prefix.
Remi: yes, implicitly.
Jari: they have different class of
service, the part I'm not fine with.
If you bind IPv6 allocation size to the IPv4 allocation size... I'm
not happy with that.
Remi: That's implied by stateless
solution.
Alain: Go to feeling of the table.
14:30-15:30 Wojciech Dec
1. Stateless 4Via6 Address Sharing
http://tools.ietf.org/html/draft-dec-stateless-4v6
Comparison
of encap and translate solutions. Majority of details are the same. Differences
lie in the context of usage. Tunneing forces changes of architecture or
constrains deployment options, eg location of functions.
Alain: MPLS is tunneling.
Woj: Different context; MPLS not used to the CPE (esp in
residential).
Remi: How is DF bit handled in translation?
Xing: As per rfc NAT64. Either copied and IPv6 extension header used,
or MTU too big ICMP message sent back. No information loss.
Woj: IPv4 functions done where IPv6
subscriber state is. i.e. on BNG.
Long discussion on the need for
features, in the network. How translation affects that. Consequence of fragment
bit on translation.
2. Stateless port mapping algorithms overview
15:45-16:15 Qiong Sun
Lightweight 4over6
http://tools.ietf.org/html/draft-cui-softwire-b4-translated-ds-lite-01
Stateless 4over6
http://tools.ietf.org/html/draft-sun-softwire-stateless-4over6-00
Sun: 94% of traffic to BR, 6% CE to
CE.
Remi: Questions of the rules. Does
it need a table for which customer has which multiplexing ratio?
Sun: Not per subscriber but fixed
per IPv4 prefix.
Alain: The rules are the same as in
divi-pd?
C: The suffix isn't used in tunnel
mode. OTherwise same as divi-pd.
Remi: Can it work with shorter than
/64
Xing: In practice not.
Remi: In the PD version, is there a
separate prefix for translation and one for native?
Xing: /64
Ole: So /56 is OK
Woj: yes.
Ole: Purpose of the suffix bits?
Xing: From dIVI
Satoru: what if port id is exceeding
the address sharing ratio?
Xing:
Jari, Woj: Discussion about features
/ classification of the translated traffic.
Ralph, Remi: DHCPv6 discussion
16:15-17:15 Xing Li
1. dIVI-pd: Dual-Stateless IPv4/IPv6 Translation
with Prefix Delegation
https://datatracker.ietf.org/doc/draft-xli-behave-divi-pd
Presented old modulo algorithm + new algorithm
dIVI PD is by default hub & spoke. Uses different prefix in the
upstream than in the downstream. Can be optimised for mesh. Allows use of /64
or shorter.
DIVI is by default mesh - requires stateful DHCP assignement (extra
subnet)
Remi, Xiao: questions on the example
of port mapping
Alain: Why is stateful translation
bad?
Xing: You need to maintain ALGs. you
cannot recover original IPv4 address when mapping back.
How
can you sync ALG on both sides of the translation
2. dIVI: Dual-Stateless IPv4/IPv6 Translation
https://datatracker.ietf.org/doc/draft-xli-behave-divi
17:30-21:00 Socail Event (depart at FIT West
Lobby at 17:30)
--------------- Tuesday 8:30-17:30
---------------
8:30-9:00 CERNET Operation Center tour (FIT
1-101, TSINGHUA UNIVERSITY)
FIT BUILDING 1-315, TSINGHUA UNIVERSITY
9:00-10:00 Gang Chen
1. 4via6 Stateless Translation
http://tools.ietf.org/html/draft-murakami-softwire-4v6-translation-00
Ole, then Alain: Comparison of MAP
algorithms scheduled for this afternoon.
Unified address mapping function
discussion stopped by chair, until this afternoon.
2. Prefix Delegation in 4V6 Tao Sun
http://www.ietf.org/internet-drafts/draft-chen-softwire-4v6-pd-00.txt
Remi: Why is multiple shared IPv4
addresses needed?
Remi: You could extend the port set
Tao: To give more port space
multiple shared IPv4 addresses.
Discussion on the meaning of
"address set".
Remi gets verification that for each
address in the set, the port range is the same.
Xing: Comments on the interface
identifier "v4 prefix". It should be subnet.
Continuing discussion on address
sets. Ole, Remi, Jari.
Alain: In Quebec we had discussion
on signalling or doing it simple. We want more flexibilty.
Xing: This is a new format. If same
as 4rd you don't need to describe it, if it is new you must.
Jari, Alain, continue discussion on
address set.
10:00-10:30 Xiaohong Deng
DS-Lite AFTR NAT Bypass: Co-located B4 and NAT
Model
http://tools.ietf.org/id/draft-zhou-softwire-b4-nat-02.txt
Alain: you don't need DHCP, you can
do port reservations only with PCP. Even 200.
Remi: Randomization within the
portset?
Xiao: If you have continuous port
set, you can randomize.
Alain: If you just do PCP requests
you will get random allocation.
Terminology
discussion on stateful/stateless
Jari: On the note of state. there is
per-flow state (e.g. TCP flows) and there is per subscriber state. that can
either be dynamic or static.
Ralph: and it matters how much state
there is from a scalability perspective.
Remi: And there are solutions that
don't have per subscriber state.
Peng:
Lightweight 4over6 draft basically describes the same mechanism
For incremental random port range assignement, ds-lite with pcp
appears best option.
10:30-10:45 Coffee break
3.Invited talks: Operator's perspective
-------------------------------------
10:45-11:15 Satoru Matsushima
An operator's view, address mapping in
particular with our cases
Alain: why the case for special IPv4
addresses in the embedded prefixes. 0/8 127/8 and so on
Remi: if the provider allocates
prefixes that belongs to the space allocated to this provider. all the special
addresses will be taken care of. algorithm doesn't have to know.
Satoru: Chained CPE discussion.
Separate IPv6 CPE and 4rd CE
Maoke: In this scenario is the IPv4
NOC and the IPv6 NOC are they different?
Satoru: Could be same, but different
policy.
Maoke: 4rd BR and 4rd CE are they
then in the same operator?
11:15-11:35 CERNET - Xing Li
The operational requiements and the experience
of the single and dual
stateless translation concerning CERNET (IPv4)
and CNGI-CERNET2 (IPv6).
Running
40G of IPv6 (translated) traffic today. 20% of overall.
Planning cernet-ng for regional schools.
Required to be IPv6 based with stateless translators. Schools to be v4&v6
Divi casues no harm:
Collected statistical data shows that fragemnts are less that 0.01% negligible
IP option use seen - some of it apparently bogus
Useful part of ICMPv4 translatable to ICMPv6
Requires operational tools to be IPv6 based not tunnel based.
Showed that this is possible today with existing IPv6 routers. Not
possible with tunneling.
Xing: CERNET2 design principle, as
complex as possible.
Cernet2 IPv6 is about 20% of IPv4
traffic.
Jari: For the fragmented packet you
need to keep state on the translators?
Xing: Yes, for 0.1% of the packets
you need to keep state.
Maoke: I'll add some information on
the UDP part. UDP fragmented is 99% is p2p software.
Remi: IF there is an IPv4 packet too
large for the translation, it will be fragmented.
Remi: Please keep somewhere. as an
informational
Woj: The original draft on v4v6
draft. was supposed to document some of these issues.
11:35-11:55 China Mobile - Hui Deng
IP fragmentation seen in the network as an issue
Running services running multiple IPv4 features. Have commits from
vendors for same features on IPv6. No such features or commits for IPinIP, and
not available.
Operationally simpler to run v4-v6 translated solution, thus not
interested in tunneling.
Smart-pipe architecture; multiple network elements.
Intention for smart pipe is to keep the same network architecture on
ipv6, rather than change it around tunnels
Encapsulation solution also shown to require complex upgrades to
control (management) plane of the network.
11:55-12:15 ChinaTelecom – Chongfeng Xie
Largest wireline bradband network. 70M subs
Remaining IPv4 address space is scattered (less that /23)
Needs: Incremental deployment, rather than complete upgrade.
Only 6% of traffic goes CPE-CPE. Rest through IP aggregation. No
split on local/vs non-local traffic.
--------------- 12:15-13:30 Lunch
---------------
FIT BUILDING 1-515, TSINGHUA UNIVERSITY
13:30-14:00 Linjian Song
Head compression
4.Divide& conquer (2 hours)
-------------------------------------
14:00-14:30 Ole Troan
Port mapping rules
Table
of must's and nice to have characteristics for port indexing/mapping algorithm
& methods
15:00-15:30 RŽmi DesprŽs
Port mapping rules
Map technologies into problem space
Goal: analyze overlaps & differences
15:30-16:00 Ole Troan
Comparision between encapsulation and
translation
16:00-16:30 Coffee break
5. Path forward (1 hour)
16:30-17:30
Goal: evolution of technologies, integration
with existing mechanism, gap
analysis
Goal: winnow down list of candidates
Chairs
Alain: Taking stock. Going through
B1, B2, B3.
Ralph: Dynamic state
A: covered in B1, B2
Wojciech making the point that there should be
agreement.
Jari: stating that the ease of doing IPV6 features
doesn't reflect the current world.
Followed up by Kevin that agreement that feature
processing is easier in translation case.
Remi: if we start from divi-pd, 4rd and 4rd-b2
then we are on the same page.
describes a
comprimise solution for mapping algorithm to accommodate translation
requirements, to get IPv4 address + PSID into the IPV6 IID. if we have that,
you can do the ACL...
Alain: rephrase. if you take this as a
requirement, you can achieve this in an encapsulation solution?
Woj: No, you are referring to the suffix part.
but that does not address the 5 tuple.
Ralph: Stating the observation that there is a
set of operators thinking that doing features in a translation solution is
easier, some that doing it in encapsulation solution.
Ralph: The translation is more unknown than
encapsulation. e.g. what happens if a translated packet is received by an IPv6 application
expecting IPv6 addresses in the payload.
Alain: Way forward.
Form a design team for proposed unified address & port mapping
algorithm PS document.
Also do a DHCPv6 option to provision the mapping algorithm.
Way forward part 2
Translation versus encapsulation
what's the consequence of CPEs.
interoperability?
what do we publish as RFCs?
(Slides)Several options regarding IETF recommendation
& document track
Ralph: Commenting on way forward. encourage
everyone to think of all the external parties, SDOs, rest of softwires, CPE
vendors, implementors. and finally as a nit, the options lists aren't mutually
exclusive.
Jari: with my AD hat on, it is important to
check this with the mailing list, and with the IESG, since they sometimes say
no.
my personal
opinion is that interoperability is important, because of this CPE issue. can I
go to bestbuy and expect that it does what I need.
also influencing the cost of running your network. my preference is
the option, based on maturity I would pick option 1.
Ralph: to follow up on cpe interoperability. in
case of DHCPv6 and PD we're finding that we have to go back and modify the PD
specification because of broken implementations.
while you cannot avoid broken implementations, then make it simple
for them
Jari: (personal) tunnel standard, translate
informational
Woj: there is an option missing. the do nothing
option.
the strength of the IETF is to formulate specifications without specifying
how operators should run their network. arguing for option 7: do nothing.
Personal opinion 5 - netural applicability statement is best; explain
tradeoffs and let industry and vendors choose.
Difference between standards and informational only matters to the
IETF
Jari: clarification. leave the decision for what
the standard for later.
Woj: standards or informational is lost on the
outside; option 5 or 7.
Alain: both can be published as experimental.
Woj: if the goal is to influence outside, then
it doesn't matter what the status is. experimental isn't the right track.
Ole - difference between the two is minimal.
Remi: option 5 is it something that tells
everything. is it combinable with technical description.
Alain: not mutually exclusive. we need to
document both an encapsulation story and a translation story. how do we do it?
and how do
we communicate some preference if we do? through a standards level or an applicability
document?
Remi: it would be easier to make decision after
having the description.
the second point, this unified address format we hope to get,
modifies the mechanisms, making them much more similar.
Jari: holding the decision is possible. it would
be expecting that the working group would like to know.. working on something for
a long time, it would good to know the end goal, but that is not something we
need to continue discussing.
Ralph: we do understand quite a bit of what the
analysis document will say, it doesn't hurt what we know today, leaving as an
internet drafts while working on the technical descriptions.
Woj: yes, we can publish the table from Ole's
presentation.
Alain: opinion from CPE vendors
Jacni: In an early stage I do care since we
do it in software. we prefer reuse of current code given the encapsulation
solution like DS-lite later we get hardware to do it, then I don't care if it
is encapsulation or translation.
Alain: asks about impact to CPE to operators.
Roberta: from the BBF we had this discussion
many times. DSlite versus 6rd discussion. BBF has modules, one for 6rd one for
DS-lite and so on.
TI as operator chooses what is needed and vendors build it
China Telecom: it is difficult for us to make
decision, we want IETF to make clear recommendation. more guidance.
China mobile: impact on CPE. I talk
with CPE vendor, we need both, depends on scenario.
Softbank: Managed CPE, we already have
encapsluation. Separated use case. wireline in encapsulation, translation for
wireless. Complexity not an issue
Orange: no control of CPE. we always provide
CPE. to different orange countries.
Xing: multimode is not a problem for CPE.
Ole: Explaining about RFC6204 CE requirements
Remi: if we have a unified mapping algorithm,...
having both translation and encapsulation lose...
Woj: it doesn't matter to the CPE, ultimately
people do one, two or none. the retail will be steared by its own forces.
if I go to bestbuy ...
it comes down to what we do with those options
we already heard
there is modularisation, the retail market compliance against both...
Woj - why the question? It's always extra code;
someone may want 6rd and ds-lite, others not - that's also complexity.
Influencing the retail market through RFCs is a non-goal. Plugging a v6-only
CPE to a ds-lite-only network will not work either, even if ds-lite rfc is
there.
Ole - modular specs being progressed through
v6ops and to other bodies, we already have v6 module, 6rd, ds-lite. This would
be another modular extension. Certification with IPv6-ready logo.
Jari: size matters. with one solution it makes
it easier. more vendors, more operators. it is not all about code.
Kevin: if we can reach one approach then it is
easier.
Tetsuya: I implemented translation and
encapsulation. want it into a single module. address mapping as a PS.
Jari: Outcome of meeting, agreement to publish
two RFCs(as per slide1) for both translation and encapsulation. Discussion on
what is to be the IETF recommendation, if any, will continue in the WG.