IETF SOFTWIRE INTERIM MEETING
Beijing,2011 September 26-27
Notetakers: Ole Troan, Ralph Droms, Wojciech Dec
0900 - Introduction section
Alain going through introduction slides.
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?
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...
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
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
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
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.
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
SA46T & SA46T-AS technology dive
ISATAP for IPv6. Map full IPv4 address into IPv6.
Ole: Questions on:
- import IPV4 routing into IPv6
- host to host
- separate IPv6 native network
- 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
Jari, Alain: How does ICMP work?
Alain: How does IPsec work?
Jari: IPsec works with IPsec NAT traversal in UDP encap.
Remi: Consequence of address sharing
Alain: A+P issues needs to be clearly documented somewhere.
Remi: The first document of 4rd was -sam.
14:00-14:30 Remi Despres
Stateless Address Mapping for IPv4 Residual Deployment (4rd)
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
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
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?
Ole: So /56 is OK
Ole: Purpose of the suffix bits?
Xing: From dIVI
Satoru: what if port id is exceeding the address sharing ratio?
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
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
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
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
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
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
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)
Goal: evolution of technologies, integration with existing mechanism, gap
Goal: winnow down list of candidates
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.