[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Minutes from Vancouver
Please find attached the minutues from Vancouver.
Best regards,
- kurtis -
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