IETF 70 IPv6 Operations
---
Monday session
	
o Agenda Bashing

  Fred walked the workinggroup through the plan for the week. WG split
  in two sessions, one on Monday on current documents.

  Thursday will be about possible translation/transition mechanisms. 

o Document status                                    30 mins

   - draft-ietf-v6ops-802-16-deployment-scenarios-04
   - draft-ietf-v6ops-scanning-implications-04
   - draft-ietf-v6ops-addcon-07

   Jari will clear discuss next week. 

   - draft-ietf-v6ops-addr-select-ps-02
   - draft-ietf-v6ops-addr-select-req-04
   - draft-arifumi-v6ops-addr-select-sol-00
   - draft-ietf-v6ops-rfc3330-for-ipv6-03
   - draft-ietf-v6ops-cpe-simple-security-00
	
o draft-chown-v6ops-rogue-ra-00                      20 mins

  Stig presented the draft. Well known problem space that have been
  seen at IETF meeting networks for example. 

  Draft presented before at the IETF by Tim. 

  Hesham: Problem statement should be that people are not deploying
  SEND. Aren't you saying that there is a solution but people are not
  using it. 

  Fred: That people are not using your solution is not a problem
  statement.

  Hesham: Well, there is an IETF standard, and there might be a reason
  why people don't use it. 

  Stig: There are very few implementations, but I would like to deploy
  it in my network.

  Brian Dickson?: Would not DAD with ??? be a way forward?

  Bob Hinden: My take is that this is one of the class of things you
  can do if you have access to LAN. 

  If you worry about things like this you might need tools to monitor
  and snoop the activity instead, so that it can be detected. This is
  an intrinsic of giving people access to the LAN. 

  Dave Thaler: So it looks like you are asking at least two classes of
  questions. Problem statement as well as a look into solution space. 

  Suresh Krishnan: If SEND get's deployed the XX can be fixed as well. 

  Iljitsch van Beijnum: we need to have two ends of a
  communication. But in this case, wouldn't it be easier if the
  vendors implemented something that I could black-list RAs. I.e
  one-sided implementaion. If I want to solve this for real I need
  SEND, but then I would need to configure trust anchors. 

  Fred: There was a comment that I could solve this in the switch, but
  not all networks like have switches. Like Wlan. 

  Francis:This can be done due to misconfiguration or malicious
  attacks. In the first case, if I connect two routers by mistake to
  the same link, even with SEND, I have a peerfectly secure,
  non-working RA. 

o draft-vandevelde-v6ops-ra-guard-00                 20 mins

  Gunther presented the draft.

  Suresh : There is no criteria for what is deemed valid in the draft?

  Gunter: It's something you know, one of the ports are dedicated for
  the router. 

  Suresh: But you do not look at the RA?

  Gunther: No. Not anymore

  Fred: I understood taht to be a local decision. MAC or whatever. 

  Suresh: But this still does not prevent mis configuration?

  Gunter: No.

  

o  draft-krishnan-v6ops-teredo-update-00.txt and      20 mins
   draft-ietf-v6ops-teredo-security-concerns-01

   Suresh: presented the drafts regarding security concerns draft. 

   Dave Thaler: Just to clarify one point. The one thing that is in
   addition to the well known implementation is the randomized
   port. Was discussed in the last v6ops sessison, and the conclusion
   was that if you are doing somehting that is not a bad thing to do. 

   Iljitsch: I had a big issue with reading in the draft that
   protocols that can't be inspected by firewalls or enforce policy
   on. This is not something that I can thing the IETF can say. We
   can't limit ourselves to only things that firewalls can
   understand. 

   Suresh: I think that was an old draft. <missed the rest>

   Alain: We are somewhat late in the game but we will have to migrate
   to IPv6. PRoviders will at some point will have to offer this to
   customers. So are we vasting time on something for nothing? None of
   the transition mechanisms really work anyway. 

   Suresh: We have already deployed some of these mechanisms. We need
   to maintain them. 

   Tony Hain: I would agree with Alain, if it was the fact that all
   application developes had their act togehter. My issues are more
   with the structure and langauge of the document beeing overly
   repetitive. 

   Alain: to answer Tony, if we look at the last few years and look at
   the through put and this wg in particular it will take us two more
   years. By then service providers should have started deploying
   native technoology. 

   Dave Thaler: I would like to support this document and it dcouments
   what is mostly done already. 

   Fred: I have a charter problem. My charter says that we are not
   supposed to cahnge protocols. AD and charis will talk to Mark who
   sponsored the Teredo work. If he agrees - as we suspect, what is
   the feeling of the room. How many thinks that we should pcik this
   up here? 

   Vote in favour to pick up as a WG item. 

IETF 70 IPv6 Operations
---
Thursday 1pm


Transition Discussion
	Review of Agenda
		Announcements
			Alain - DHCPv6 bake-off and conformance
			testing this weekend.

			Hiroshimi - Please read draft on IPv4/IPv6 translator

	Jordi Palet - Measuring IPv6 Traffic 
	      	Operators were commenting
		that < 5% was IPv6. Were they only counting
		IPv6-native traffic?  Developed pcap-based tool to
		identify native and tunnelled IPv6 traffic (including:
		6to4, teredo, proto-41, etc). Also classifies source
		by region (by RIR) Results 
		   67% of all packets are IPv6
		   45% of all traffic is IPv6 by bytes
			
		   48% teredo
		   46% 6to4

		   Measurements were done in Europe (ES)
			
		   13% of traffic is native IPv6 (by byte-count)

		   General trend of increasing IPv6 traffic

		   Tools are stable, so looking for ISP in every
		   region to run these tools - collecting statistics
		   per region to compile a "state of IPv6".

		   Note: The samples came from an operator who runs
		   both 6to4 and Teredo relays - this may influence
		   the results however Jordi does not consider this to
		   be significantly influencing the results.

		   ISPs may have much more IPv6 traffic than they exist

		   Comments: These results are only representative of
		   	     a single carrier who operates IPv6 relay
		   	     services - it isn't representative of
		   	     other networks These statistics will make
		   	     more sense if they are run in an
		   	     environment that doesn't operate a IPv6
		   	     relay


	Marcelo - IPv6 to IPv6 Translator Problem Statement and Analysis 
		Many of the translator drafts looked very
		different. It might be an interesting idea to
		understand what we can change, what we cannot change. 

		We need to make a decision what we will support and
		what we will not.

		Depending on which type of application behaviours that
		we want to support, the design of the NAT box may be
		completely different

		Classify applications and identify their requirements
		on the NAT box

			Several application behaviours (documented in
			draft and slides)

			Traffic can be initiated from either side (v4
			or v6)

			Includes unidirectional traffic; "call-back"
			traffic (bi-directional); or, referrals -
			where nodes may tell other nodes about traffic
			destinations

		What application behaviours are we going to support
		when we implement NAT translators

			Could just support current NAT behaviours

				IPv6 nodes communicating into the IPv4
				world
				Implement all behaviours of current
				IPv4 NAT for IPv6?

		Some drafts change IPv4 hosts, some change IPv6 hosts,
		some change both of them

		Other considerations

			What are the application scenarios

				Where are we going to place this box?
				At the end-site (customer) or in the
				ISP?

			Transparency - are the nodes aware of the
			existence of an IPv4/IPv6 translator? 

		
		Comments:

			Ed - Are we ready at this point to rule out -
			making sure we are not trying to rule out
			certain behaviours just yet. This is useful to
			compare the behaviours of current proposals
			and supports the 

			Eric - The transparency and what parts you
			need to change seem to have a lot of overlap. 

					>You may need to update nodes,
                                         but you may not need to have
                                         explicit communication with
                                         the box

				You assumed the v6-world only had v6,
				but what about legacy hosts? How do
				you capture this?

					>These were not network
                                         diagrams, just translation
                                         behaviours

				But if v6 is only on one side, it is
				easier that whether v4 exists on both
				sides

					> Why would you translate if
                                          you have native v4

			Miyakawa - Do ISPs need NAT64? NAT64 is not
			acceptable in the backbone or core of the ISP,
			as there is too much state in the network and
			is at risk for DoS. I do not think general
			purpose NAT64 will exist in ISP. What about
			Dual Stack - single stack is still 10 years
			out. Application specific NAT64 (restricted to
			certain services) may be useful. It is useful
			to split out general purpose and app. specific
			services

			Houston - This doesn't seem to have anything
			in common with existing IPv4 NATs (other than
			the name). Are we getting confused by IPv4 NAT
			terminology and are trying to apply these
			principles to IPv6. This approach will not get
			you anywhere if we assume this is a kind of
			NAT - it is not a NAT as we knew it - consider
			abandoning the NATv4 concepts.

				> All the application behaviours come
                                  from a non-NAT world.

				Geoff didn't see anything that was
				obviously application-specific.

			Hiroshimi - We need to set a goal, and it
			should depend on the deployment scenario. What
			is the approach to the translation issue? The
			analysis should be conducted - are all these
			models really used in the world?

			Jordi - Inside is probably not a good use of
			terminology. Instead of using "ISP Inside",
			use in the ISP, in the CPE or in the
			host. Should you put this in the ISP -
			security problems

			- Where are application embedded addresses
                          described - this may be missed. 

				> Isn't this a callback?

				Isn't a callback something that needs
				long-lived state?
				> No distinction was made  - example
				FTP. It could be split into
				short-lived and long lived.

				Need to separate out the embedded
				address problem (within applications)

	
	
	Alain Durand - Sharing a single IPv4 address among many
	broadband customers

		10-15 years ago we assumed we would have moved to
		dual-stack and this would have occurred before IPv4
		run-out. This didn't happen so we need to consider
		something different.

		The Internet is running out of IPv4 addressed. The
		Internet edges (hosts in the home and content
		services) are IPv4

		Home computers are not replaced regularly - 5 years
		plus. Windows XP does not support IPv6-only. Simply
		focusing on new devices with IPv6 is not an approach
		as I must provide services to existing hosts
		(including Windows XP)

		Most web servers are IPv4 - it is going to take a long
		time to have all the content servers to IPv6

		The ISP (in the middle) may need to change something
		to make these IPv4 services work when run-out occurs

		We cannot afford to give a single IPv4 public address
		to each customer. It must be shared among many
		subscribers. This will allow "legacy" hosts to access
		the IPv4 internet.

		Options:
			Instead of provisioning them with an IPv4
			address, we only provision them with an IPv6
			address. The default is not giving an IPv4
			address - IPv4 may be at additional
			costs. Assume we can upgrade the CPE/home
			gateway.

			Double NAT for legacy home devices. IPv4 to
			IPv6 to IPv4. The ISP does not need to
			maintain IPv4 in the access networks. The
			service provider maintains a translator that
			converts IPv6 into IPv4. How would we scale
			this?

				In the home, use NAT46, in the ISP use
				NAT64. Could use DHCPv6 to configure
				the home gateway. The home gateway
				uses an IPv6 prefix for translation to
				and from IPv4.

				DNS can be translated, or the home
				gateway can be a DNS proxy

				MTU adaptation. IPv pMTUd between
				servers. May not be such a big issues
				based on analysis.

		FAQ
			Why not use tunnelling instead of NAT?
				Because you would need a IPv4 address
			Why not use double v4 NAT
				You would need private addresses and
				the RFC 1918 pools are too small to address
				all customers

			Why not have home v6-only and translate in the
			home gateway?

				Will not help legacy v4-only devices
			What about new v6-only hosts trying to reach
			the v4 internet

				Not addressed
		
		Shin - We can divide a network into regions. We do not
		see a problem with 10/8 pool size. JPNIC has proposed
		to APNIC that a address space is proposed for the
		purpose of translation so that it does not overlap
		with RFC1918 addresses in use. Define another IANA
		allocation for service providers to use. No issues
		with double NAT

			> Islands of overlapping space make it hard to
                          have visibility across the entire network.

			If you can control the CPE, you might be able
			to do something like you propose - but this
			may not apply to all environments.

		Eric Vine - Why dont you just encapsulate the IPv4
		packet in the IPv6 tunnel.  Why cant you just NAT at
		the outside

			> You can identify individuals because they
                          are tunnelled

		- Requirements must be clearly identified for
                  broadband providers. 

		Eric - Do you have requirements on the NAT in the ISP?

			> Distribute the NAT64 as close as possible to
                          the customer. So only 20,000 customers per
                          translator (order of magnitude)

		Ralph - This is a particular deployment of
		NAT46/NAT64. Is it a particular deployment, or are
		there features that need to go into these translators
		that must be fed into the working group?

			> The home gateway NAT46 is not stateful. The
                          NAT64 should be the "generic IPv6 to IPv4
                          translator". But what is the packet
                          encapsulation/IPv6 addressing that will be
                          compatible with these NAT64 generic
                          translators.

			So there may be specific modes of translation
			to consider - these are not two NAT devices
			doing the same thing.

			> Correct
	



	Elwyn Davies - Requirements and Other Considerations for
	NAT-PT Replacement

		A lot of the failings of NAT-PT were attributed to the
		DNS ALG.

		What requirements and issues can we draw from RFC 4966
		and discuss architectural trade offs.

		The major issue was the use of the DNS
		ALG. Synthesised AAAA addresses from A. DNS responses
		were no longer globally valid. If you do change DNS
		responses you must not violate the semantics of
		DNS. Possible use this in the host instead of the
		gateway - issues of multiple resolvers and this
		requires a modification of the host.

		RFC 2766 aims for transparency and autonomous operation.
		What are the options for any new solution that we bring up.
			We could stick with transparency.
			Could allow the IP stack to become aware of
		the translation going on. Should we modify the IPv6
		host, IPv4 host or both? I can't see that changing the
		IPv4 stacks is sensible of feasible. I believe it is
		IPv6 stack only.

			Allow the host stack to be aware of
			translation instead of requiring it to be
			aware.

			Allow or require applications on the host to
			be aware of the translation?

			This awareness is not a binary value -
			different degrees of awareness that could be
			put into the host.

		
	If you did have awareness in the host, you might be able to
	achieve an ALG-free translator. A single generic box that is
	good for all time and new applications just work.

		You might be be able to select a translated connection
		only when required. Unawareness of a translator
		promotes lowest common denominator situation

		Could control the connection from host to gateway
		
		If you do put awareness in, there are downsides.
			Deployability - more work to convert
			applications if it is required

		Some issues in RFC 2766 can be fixed with minimal
		awareness. Perhaps we can identify IPv6 translated
		addresses by prefix?

		Is there a way to provide a universal ID that works
		across IPv4 and IPv6? SHANTI is existence proof of
		this

		RFC 2766 does not translate multicast. Not sure
		whether this is a big problem. Proposals in the
		pipeline - must make a decision

		RFC 2766 breaks Mobile IPv6. How important is this?
		Co-locating NAT-PT and the Home Gateway may help

		Scalability
			Dynamic selection of the gateway? Single point
			of failure vulnerability reduction.





	Dave Thaler - Transitioning to IPv6
		Lots of entities involved, hosts, servers, networks,
		local networks. They don't all move towards IPv6 at
		the same time.

		IPv6 apps talking across an IPv4-only network. Most
		work done here.

		IPv4 capable apps talking across an IPv6-only
		network. Has been mostly delayed.

		IPv4-only app talking to IPv6-only device and
		vice-versa. NAT-PT, BITS, BITA, TRT.

		Scenario caused by IPv4 address scarcity. Port is
		fixed, what about a legacy host that needs to talk to
		the dual-stack server, but IPv4 is behind NAT. This is
		a gap in the IETF. The IAB needs the IETF to consider
		this scenario. A poor story is better than no
		story. Remember this is for IANA-reseverd static
		Ports. 

		
		Comments
		Tony - As we develop a list of things we need to pay
		attention to - your diagrams do a good job. Alain is
		trying to solve something else - we need to separate
		the two different issues.

		> Yes. 
		David Hankins - Chose a bad example for
		application. HTTP has a host header, so you could use
		that.

		Alain - Are you looking at this for an enterprise
		environment or home network?

		> Intentionally ambiguous as it could apply to
                  different deployments.

			Important to make a distinction between the
			different environments as different networks
			may need this "fixed" in different ways. The
			qty of addresses saved is a big decision
			factor.

		Ralph - How did this get referred?
		> IAB requested IESG to ask the IETF to fix this. 
			Why did they ask?
			> Its a gap and not being addressed.
		Chris - I don't think the IETF should try and figure
		out what kind of environment is a home or
		enterprise. We still need to solve it - its IP.




	Iljitsch - Reviving NAT-PT
		In response to plenary - the content people do not
		have a problem. ISPs do have a problem, new addresses
		for new customers. 

		The dual-stack problem doesn't solve anything for
		end-users. You still need everything you need for IPv4
		and IPv6 just adds complexity

		NAT-PT solves the interoperability issue. Make "fake"
		AAAA records from A records. 


	Iljitsch - SHANTI
		It shouldn't be any worse than you get today with NATv4. 
		Upper layer protocols can talk IPv6 to IPv4 , there is
		something in the middle that makes IPv4/IPv6
		translator through the use of a SHIM in the stack, and
		a translator device. Distributed IPv4 stack.

		DNS - suggest the resolver maps A records into AAAA
		records expanded with ::ffff:/0 - note that these
		never appear on the wire because of shimming.


	NAT-PT
		Remove the fake AAAA records and provide the original
		A record. 		IPv4 to IPv6 - use DNS to find
		the mapping.


	Comments:
		Eric - lots of SHIM6 terminology but no detail on
		SHIM6 itself. Will double translation between v4 to v6
		get us into more trouble? Don't we need to consider
		where to tunnel it? Going back and forward means we
		lose some things. What about tunnelling?

		> The reason I do translation: 1) IPv4 header needs a
                  source address anyway 2) IPv6 application / IPv4
                  application , IPv4 host - for the translator it is
                  all the same thing

		- Can we describe the SHANTI solution with different
                  terminology? Suggest we may look at this more - how
                  do we build distributed IPv4 stacks?

		- Address translation is also considered in routing
                  research group for multi-homing. Can we come up with
                  one proposal that fits both forums? 

		Alain - I like the mapping you create between v4 and
		v6 address - could work between v4 and v6, and between
		v4 to v6 to v4. We could use the same translation
		method in both devices. (NAT46 and NAT64).

Alain:
        Shanti is attaching itself to the SHIm6 proposal
        > Not using SHIM6 it is ripping out 80%+ of the SHIM6 proposal
        Implemented on IPv4 side so non-starter?
        > No only requires changes on the IPv6 side.
        Does not require any changes on the IPv4 side
        > That is correct

David:
        v4-to-v6 proposal OK
        Martian address space a problem
        > Can use anything else
        Might want to consider doing address translation closer to the
        subscriber rather than centralising it into the network
        > May be a valid approach





Where do we as the IETF need to be going?
	- Should this work be done
	- If so, what are we trying to solve, what are we not trying to solve?
	
If its an expensive bandaid, we may have it for a long time. If we do
work on a translator we need to use existing technology as much as
needed.

	

Comments
	- The party that has the greater interest in making
	translation work should make the changes. We need it in both
	stages

	- You opened the question with a solution space. What about
          tunnelling? We could restrict the tunnel endpoints. What are
          the questions we are trying to solve? Starting from scratch
          and designing a new NAPT will push us well past the date we
          run out of v4

	- Jordi - Saying the same thing. Isn't a lot of this sorted
          out in the softwires wg? Perhaps we need something else -
          the new case when we have IPv6-only servers.


	- Jari - we need to decide whether we will modify the IPv6
          host/stack. It's clear we cannot change the IPv4 stack.

	- There may be IPv6-only devices such as low-powered 802.15 devices.
	- We need to separate DNS ALG from NAT technology.
Jordi:
	We don't have a solution when you turn off IPv4; that's where we need
	a translation mechanism.

Alain:
	Thank you Jordi for telling me how to run my network.
	Are we going to end up in a world that is worse than we have now?
	Is it wise to move forward?
	When I look at v4 translation using some form of private space in
	the middle and this is going to get us deeper into v4 and multi
	translations. No light at the end of the tunnel(s).
	
	If I look at IPv6 to the residence with a v4 translation (v4-v6-v4)
	then it brings v6 to the residence and gives an incentive for the
	content provider to move to v6. The customers have two paths to the
	world. Over v6 it provides a better experience and an escape path from
	the multiple translated v4 mess.

Marc:
	Same comment as Tony.
	We need to define the use cases and deploy whatever technology we have
	right now. See if that works, before doing more protocol development
	and dirty tricks. That is the v6ops mandate.

	We need to be careful about going too fast in protocol work.

Hiroshi:
	double or triple translation will be required and will happen.
	Nobody knows or has tried it; more research/experiemntation required.
	
Erik
	It sounds like a good idea to get some experience / test experience

	Looking at tunnels, what is practical? Reverse proxy may work and
	should not be discarded (limited application)

	Other tools in the toolbox - no feeling for what has been tried out
	there.

	It would be useful to hear what other people have tried. Harvest
	research from people - try new things.

	NAT-PT and taking out the DNS-ALG sounds like a useful tool.
	Two pronged: go learn more stuff; and do the modifications to the NAT-PT
	as required.

David Miles:
	From an operators perspective is a desire to change CPE.

	CPE is going to be in a static state until something new comes around.
	v4 is done well; some do v6 as well. Don't believe we can change the
	ipv4 host to make them work any better. reality is that a lot of the
	v6 hosts are not going to change either.

	This is about timing: wee can deploy dual stack and SP-NAT. The BEHAVE
	WG is helping to do P2P without the need for ALG. There is a toolkit
	that can allow a v6 deployment to occur in conjunction with v4. the
	problem I see is in the earlier slides, a dual stack device that is
	running a service of some kind behind NAT where there is reserved
	port (or multiple demand for that port) is the issue.

	The operators are looking for solutions today; identify gaps.

Iljitsch:
	Parallel development as per Erik's statement makes sense.

	Tunneling vs trranslation - tunneling is going to be harder. This
	will require modifications (v6host etc).

	Proxying: https proxy is generic tcp proxy. Can do any TCP protocol
	and can be deployed today/tomorrow?

?:
	We need to reconsider this from the more fundamental viewpoint:
	simpler is better.

	What is the simplest method? We need to identify this. The complex
	solutions will never be used.

	We need to compare which is easier (move to v6; or translator)

Jari:
	Alain's presentation is interesting; solution may not be the correct
	one but it is worth researching.

	We need to identify what we need to do.

	Which nodes have to be modified? The v4 side cannot be modified. Can
	only modify the v6 host. Are we prepared to bite the bullet and have
	v6 host modifications? Is it practical to expect that it will
	work without

	modifications