I've submitted a new revision of the rfc2462bis draft:
draft-ietf-ipv6-rfc2462bis-00.txt
on the issue of DAD and loopback suppression outlined in appendix A.
I've seen a couple of cases in the past where DAD packets could be
looped back by the network. this could happen if there is a temporary
On Thu, 12 Feb 2004 00:07:39 +,
Ole Troan [EMAIL PROTECTED] said:
one solution could be to add a optional identifier option to DAD NS
packets, so that the sender can recognise the case when its own
packets are looped around.
too big a change for 2462bis?
I think this is too
Greg,
This essentially the problem with DAD on wifi, right? That should
make a general solution more interesting then just a corner case.
no, this is a general problem. I've seen this on Ethernet.
I've spoken to the DAD/WIFI draft owners and we've agreed to add the
id option to that draft and
Pekka,
This started from me looking at draft-bykim-ipv6-hpd-01.txt, what it
was before that, DHCPv6 + PD, a few proposals at v6ops for integrated
prefix delegation, etc.. -- I couldn't help thinking, there must be
an easier way to delegate an IPv6 prefix in the simplest setups (e.g.,
when v6
Pekka,
[Ralph:]
.
The CLI sets up a pool of prefixes for delegation(1), associates the prefix
pool with other DHCPv6 server configuration information (2) and enables the
server on an interface (3). In this example, there is no customer
identification or authentication (which is
the amount of work required to implement PD using a DHCP based
protocol engine versus an ICMP based protocol engine is similar. the
benefit of reusing DHCP (ignoring the fact that its already an RFC and
has numerous implementation) is that the cost of implementing and
deploying all the N++
I'd sure be interested in hearing what others in the WG think
on this issue.
I agree with Erik.
I see two alternatives:
1. ND proxy. Limited to single router, proxy from uplink to
downlink. No need for loop detection.
2. Multilink subnet routing. Handles arbitrary topologies. Must
One of Major Core Router vender is not advertising Interface Identifier as
part of IPV6CP Configuration Request. The control packet from that box is as
given below.
80 57 01 28 00 04 (no Interface Identifier options).
Even I send Nak for this message with Interface Identifier option,
Vishwas,
You said There is no difference between a tunnel link and any other
link media I think.
That is the exact issue in my case for ND messages. If we just send a
packet tunneled, the TTL check for ND messages fails as we can send a
packet from multiple hops away by just adding another
I don't understand the rationale for this work either.
the first PD proposal (by Brian Haberman) was indeed based on using
ICMP as transport. separate message types instead of
piggy-backing on RS/RA though. as we continued to develop that
mechanism we realised that we were pretty much reinventing
Should (can) something like the following be added to the draft ?:
Conformant implementations of IPv6 hosts and routers MUST not
provide a way to activate RH0 processing on the system.
This is a very bad idea for two reasons:
1. The IPv6 spec says that you MUST implement it, then having
If you say this language should already be in the 2461bis where is it
? Show us the exact paragraph and section.
Please note that both an implementer of a popular IPv6 host and an IPv6
certification agency missed this behavior.
5.2. Conceptual Sending Algorithm explains how a host should
Let's talk specifics, not generics. Of course, we know about section 5.2
of 2461bis.
Snipped is following text from Introduction section of our I-D as to
what we think about section 5.2 of 2461bis:
Sections 5.2 and 7.2.2 imply that the host performs
address resolution before
Came across this thread...
http://www1.ietf.org/mail-archive/web/ipv6/current/msg02314.html
However, in looking at draft-ietf-ipv6-over-ppp-v2-03, it seems that
this issue was never addressed.
Is this intentional? Was there ever an agreement that ND should or
should not be done
I think it's easy to see the disagreement just comparing the responses
from Ole and James.
Ole says:
I don't see the point of doing address resolution on links without
addresses.
James says:
IPV6CP (RFC 2472) negotiates
only interface identifiers, and not addresses, and ND
(2461) says
I think it's easy to see the disagreement just comparing the responses
from Ole and James.
Ole says:
I don't see the point of doing address resolution on links without
addresses.
If you've actually got links with no addresses at all, then I agree.
That seems odd, though, given the
All I am saying is, if IPV6CP is used to negotiate one interface-id,
when multiple addresses, that Dave pointed out, are needed for the same
client, why not use IPV6CP to negotiate interface-id's for even these
addresses?
We'd have to discuss that on the PPP list, but my take on it is that
Never mind, I found what's 2462bis. I got hold of
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-over-ppp-v2-03.txt
I read this draft and I find it severely lacking. At the very least, to make
using IPv6 over PPP even remotely usable, it should include the following
options:
1. An
FYI,
This issue, from cisco-nsp list, might be of interest here. When an
interface is looped, it will fail DAD, and if the condition lasts long
enough, you might not recover from it automatically.
this is a flaw in the way DAD was designed. one solution could be to
add a nonce option to ND.
2008/6/6 Alexandru Petrescu [EMAIL PROTECTED]:
Hemant Singh (shemant) wrote:
Silviu,
A router can receive an RA on the router's upstream
Yes it can. It uses it to report whether some things went wrong, log
stuff, but don't act.
and use this RA to autoconfigure the ipv6 address on
I have a couple of related questions regarding /128s:
1) can a requesting router use DHCPv6 prefix delegation to
obtain /128's from a delegating router?
yes, but that seems a little contrived.
2) Must a requesting router examine the MO bits in another
router's RAs before determining that
RFC 4443 describes how to deal with an IPv6 packet with hop limit field set
to 0 when a router receives it.
RFC4443, Section 3.3:
If a router receives a packet with a Hop Limit of zero, or if a
router decrements a packet's Hop Limit to zero, it MUST discard the
packet and originate an
Mikael,
Um, what does a router do? Look at the example in the text and ask
yourself if you want an average user (my canonical average user
being my daughter, who wanted me to come to her house to install a
camera on her computer so she could use it on Skype - did you try
plugging it in?)
Barbara,
I'm sorry if the following questions show my ignorance, but, here
goes...
Why does it need to be a dynamic routing protocol? Why not a simple
configuration protocol, like with RFC 4191 or a DHCPv6 option as
suggested in
http://tools.ietf.org/html/draft-dec-dhcpv6-route-option-01?
Why
Yiu,
IMHO, it is high bar for the operators to support dynamic routing
protocol
for residential customers. Today, each access router can easily
support
thousands of customers. Imagine the access router needs to receive
thousands
if not millions updates every few minutes, I am not sure the
picking up an old thread.
[...]
- DHCP and stateless autoconf. This document is probably not the
right place to discuss the MO bits, but IMO this document should
say more about DHCP vs. stateless and the issues surrounding when
to implement one or the other. Not to mandate them.
routers should never treat /64 as special or as any kind of limit.
It's just a convention that /64 is
considered the longest normal subnet prefix, which happens to be
compatible with SLAAC
not trying to speak for every platform or operating system that Cisco
has, but this is what's been
hi,
a question arose from work I'm doing with the BBF and their CPE requirements
document (TR-124/WT-192). an issue has been raised with regards to a
requirement about CPE routers automatically offering ULA addresses on the LAN.
in the case of multiple CPE routers on a link, the suggestion is
the whole problem?
- do we need any IETF work to cover these 'gaps'?
- is this a problem which should be solved?
cheers,
Ole
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] On
Behalf Of Ole Troan
Sent: 12 January 2010 18:51
To: ipv6@ietf.org
Subject
specification describing how this should work? is it a
problem we need to resolve? e.g could we just say that having two ULA prefixes
in the network is fine. or we just state that this is a problem which require
manual configuration?
cheers,
Ole
On Jan 12, 2010, at 7:50 AM 1/12/10, Ole Troan
Fred,
I don't see anything in the RFC about the behavior of routers in this
context; in point of fact, I don't see anything about routers coming up and
finding each other. I would interpret that as routers are expected to be
configured, manually or dynamically, as opposed to determining
Brian,
It appears from the discussion that the network administrator is trying to
get *multiple* Linksys/equivalent systems to work together with no
intervention (and potentially with multiple, independent ISPs). None of the
people who I know who have such a setup with IPv4 expect this to
a comment on section 5.8.5 on stateful address autoconfiguration.
5.8.5. Stateful Address Autoconfiguration
Stateful Address Autoconfiguration MAY be supported. DHCPv6
[RFC3315] is the standard stateful address configuration protocol;
see Section 6.2 for DHCPv6 support.
Nodes
Yeah, I think that after the bloody simple-security debates of the past
week, that many are amazed that anyone on this list was able to miss the
carnage. Anyway, the current CPE router draft has the following security
requirements in section 4.4:
S-1: The IPv6 CE router SHOULD support
James,
indeed, apart from the fact that it does not/will not make any
recommendation about default on or off.
If the editors of I-D.ietf-v6ops-ipv6-cpe-router would like to host the
debate over whether or not to make such a recommendation, then that would
make me very, very happy. We
Brian,
Picking 6man as a likely list to discuss this draft...
apologies for the delay. on holiday, but it is raining in Rio today so I might
as well do email.
Three high level comments:
1. When we did the work that led to RFC 3582, a very clear consensus
was that transport-layer
I agree with Dave Thaler from yesterday’s discussion in 6man related to the
/127 draft. In the two router scenario for /127, each router is off-link to
the other and then one has nothing to bother about for anycast address.
Folks are also encouraged to read the IPv6 Subnet Model RFC where
Dave,
my view is entirely different.
the 64 bit boundary is a suggested policy and not normative.
That's not true. RFC 4291 is the addressing architecture and normatively
states:
For all unicast addresses, except those that start with the binary
value 000, Interface IDs are
as you say, the loopback discussion is a 'red herring.'
the subject is really simple. on p2p inter-router links many of us use
/31s and /127s. they work well and meet our operational needs. there
are some documents which muddy the use of /127s. we want it made very
clear that /127s on
Hemant,
So this p2p ethernet could still be traversing over SONET in which case,
again, routers do not let ND be configured over such a link. Anyway,
even if not SONET transport, if you have p2p inter router link, doesn't
each router have more network interfaces over which ND and Redirect
Hemant,
I don't understand either. Why is it an issue for a sender node to
transmit a packet on the link-layer as a unicast message, if its known
there is only one receiver. I've not seen a single valid argument and
so its fine, one is entitled for their opinions.
This is the email I sent
Jeroen,
Unless you configure two /128's pointing to the remote side, which will
then thus not be 'on-link for neighbor discovery, the little thing
called the subnet anycast address will make sure that a /127 ptp simply
does not work, unless you have a platform which disables the subnet
P.S.: This fix doesn't prevent the use of /127s (it's orthogonal),
Unless you configure two /128's pointing to the remote side, which will
then thus not be 'on-link for neighbor discovery, the little thing
called the subnet anycast address will make sure that a /127 ptp simply
does not
On Aug 16, 2010, at 20:34 , Christopher Morrow wrote:
On Mon, Aug 16, 2010 at 7:54 AM, Ole Troan o...@cisco.com wrote:
one could equally just make a convention to use link-locals with fe80::1 and
fe80::2
and /128s on each side if one needed global addresses for sources to
traceroute etc
Jared,
Please explain how ll would solve the problem first. Maybe the bcp38+1918
thread on nanog on recent days would be instructive.
which problem? there are several.
with regards to the NANOG reference, I don't quite see the similarity. I
haven't seen any implementation sourcing packets
one could equally just make a convention to use link-locals with fe80::1
and fe80::2
and /128s on each side if one needed global addresses for sources to
traceroute etc.
no, ping/monitoring/data-collection fails in this case. (or needs to
be overhauled to collect/test/monitor in new/fun
please ping my router, it's interface address is: fe80::20e:cff:fe5c:b001/64
my monitoring system can't ping this to ensure liveness of the
interface either :(
but they can ping whatever global /128 you put on that interface, so why
doesn't that solve the problems?
Because you are
please ping my router, it's interface address is:
fe80::20e:cff:fe5c:b001/64
my monitoring system can't ping this to ensure liveness of the
interface either :(
but they can ping whatever global /128 you put on that interface, so why
doesn't that solve the problems?
Because you are then
Seiichi-san,
BGP peerings and what not could use link-local addresses. e.g:
router A -- router B
fe80::1fe80::2
dead:beef::1/128 c001:cafe::2/128
if
I get a BGP neighbor down message with fe80::2
then
what address do I ping, trace? I can
Thus, do ask Cisco and Juniper and other vendors where this now
'works' if this intentional, or if they might finally comply to the
IPv6 specifications one day, as then you might better watch out for
this as it will break your network. For the vendors that have it,
it might maybe be an idea
Its the same issue for DHCPv6, if the client dont send a DHCP_Solicit you
dont get an address. Also, the RS similar to the DHCP_Solicit is used to
kick_start the IP Sub session and as you know there are lots of hosts whom
dont have a DHCPv6 client and will not have a DHCPv6 client.
The
Suresh,
that wasn't quite the question I asked. DHCPv6 has a well defined mechanism
to periodically retry, while RS client sending simply timeout. This would
seemingly leave such clients in the proposed scheme with no connectivity.
I do see your problem, but that problem is common to all
Alan,
Don't you have that same problem regardless of the LIO?
If you have an IPv6 host directly connected to say your loving Residential
Gateway and it sends 3 RS messages you have the same issue, right?
Also, the likelihood of losing 3 RS messages are highly unlikely, you would
have
Olaf,
thx for your comments. I nearly forgot that an ISP has to offer its customers
a good service, thx for reminding me ;-).
I'm just inserting as an answer a sentence, I found in an email posted by Tom
Petch on this mailing list in another context:
Tom Petch wrote on Fr 10.09.2010
Olaf,
let us say we have 5 classes of host implementations:
1) IPv4 only and those which will never be upgraded with IPv6 support
2) partly broken IPv6 support and without DHCPv6
3) partly broken IPv6 support with DHCPv6
4) full IPv6 support without DHCPv6
5) full IPv6 support with DHCPv6
Suresh,
4) full IPv6 support without DHCPv6
5) full IPv6 support with DHCPv6
by partly broken I mean lacking dual stack / IPv4/IPv6 multihoming support.
i.e happy eyeballs or having other serious short comings. I do not want to
enable IPv6 on hosts implementations that e.g have 75 second
Sursh,
let us say we have 5 classes of host implementations:
1) IPv4 only and those which will never be upgraded with IPv6 support
2) partly broken IPv6 support and without DHCPv6
3) partly broken IPv6 support with DHCPv6
4) full IPv6 support without DHCPv6
5) full IPv6 support with
I've finally caught up on the discussion about rs-mark and the N:1 VLAN
model. One of the key technical issues is how a SLAAC host recovers should
its three RS messages be lost.
Can someone explain to me how this works with SLAAC in the 1:1 VLAN model?
It seems like the router would
Mikael,
[changing subject as this has departed from discussing the RS mark draft]
I think the technical issue there is that ND and RA were designed as a
package, and you certainly can't run without ND.
Well, the DHCPv6 standard can be changed to hand out information so ND isn't
needed.
Mikael,
I don't understand what you mean when you say ND isn't needed.
basic ND has this set of functions:
Router Discovery
Prefix Discovery
Parameter Discovery
Address Autoconfiguration
Address resolution
Next-hop determination
Neighbor Unreachability Detection
Off the top of my head, I thought about a new rule to the RFC 3484.
It's really a simple rule, and seems to solve several problematic
cases related to address selection.
The rule is:
Prefer to select an address as the source address that is
assigned by the selected next-hop.
This rule
David,
good point indeed.
perhaps it is time for the IETF to acknowledge the fact that these link types
are common and to take a more architectural and wide approach to solving and
adapting its protocols to this subnet model.
I'm concerned that we are standardising point solutions without
I've been telling people for years that with IPv6, you don't need a global
scope address on an interface. The routing protocols use link locals, so they
don't care. And should an ICMP message need to be generated, the source
address is filled in with a global scope address borrowed from
It doesn't. The I-D aims at allowing routers specify which policy they want
hosts to employ when generating their IPv6 addresses.
Uh? I definitely don't want to give the router at Starbucks the means to
specify the privacy configuration of my laptop.
I understand that corporation want
I'm on the fence with regards to this document. if this document is meant to be
the RFC1122/1812 document for IPv6,
I think we are too early in the deployment of IPv6 to have gathered enough
experience with what works and what doesn't.
as a profile of an IPv6 node though, it isn't too far off.
Thomas,
Thanks for the review!
I'm on the fence with regards to this document. if this document is
meant to be the RFC1122/1812 document for IPv6, I think we are too
early in the deployment of IPv6 to have gathered enough experience
with what works and what doesn't. as a profile of an
Thomas,
Can someone explain to me the rationale for mandating 4191 in 6204?
What was the scenario that was envisioned that necessitates 4191?
it was the only way we found to keep support for ULA prefixes. the
scenario is if you have a home CPE with ULA enabled, but no upstream
IPv6
To put it another way, if we think there is a good use case for this
as Ole describes, we will be doing a service to the devices that
don't have their IPv6 code yet, to make it a SHOULD so they are
more likely to implement it.
Here is some proposed text:
5.3. Default Router
Karl,
For situations apparently needing the subnet router anycast address,
there is the all-routers-on-link multicast address. Not that it would
normally be needed, because any node on the link has (or can cheaply
build) a list of all routers on the link by just watching the RAs,
something
Francois,
I try to ping some routers on one of their Subnet-Router anycast addresses
(SRAA).
(http://tools.ietf.org/html/rfc4291#section-2.6.1)
Some (Cisco) reply with an unicast source address (same subnet prefix).
Another one (Alcatel) reply with the SRAA as source address.
A Linux
Francois,
Section 4 of RFC 3484 states:
(http://tools.ietf.org/html/rfc3484#section-4)
4. Candidate Source Addresses
[. . .]
In any case, anycast addresses, multicast addresses, and the
unspecified address MUST NOT be included in a candidate set.
Are a reply to
I think 20 bits should be already be more than enough. For simplicity,
I would
just go for 64 bits.
Appreciate the quick reply. Note BrianC already noted that 20 bits will
not suffice by saying It puts you into birthday-paradox territory on a
LAN with a few hundred nodes.. His email is
Hui,
why not just merge all the information received?
e.g. if you get DNS server over DHCP and RA, use all.
if you get addresses via SLAAC and DHCP, you use all...
cheers,
Ole
On Nov 14, 2011, at 9:46 , Hui Deng wrote:
Hello 6MAN and DHCP,
Especially thanks Wes Beebee, Hemant Singh,
Karl,
why not just merge all the information received?
e.g. if you get DNS server over DHCP and RA, use all.
if you get addresses via SLAAC and DHCP, you use all...
It's about *conflict*, I think.
I.e., when the information coming from RA and DHCP cannot be merged -
for example,
Ted,
why not just merge all the information received?
e.g. if you get DNS server over DHCP and RA, use all.
if you get addresses via SLAAC and DHCP, you use all...
Because just merge is essentially equivalent to just walk across the river
without your feet getting wet.. If you can write
isn't this what a host does anyway? if it has more than one router on the
link?
Yes, and they reliably do it wrong. This is why we have a MIF working group!
:)
wouldn't they continue to do it wrong if we were to specify a default policy?
I'm in the camp of use all the information you've
Karl,
can you give examples of what information cannot be merged?
certainly a default router list can be merged...
If one source says that the domain search list is a.com b.com c.com
and another source says it is c.com a.com b.com, how can you merge the
search lists?
Or if one source
I know Prefix Delegation. I want to know if there is any RFC /
specification said that what protocols should support PD.
RFC3633 / RFC6204.
RFC3633 _is_ a protocol. I don't understand what you mean by what protocols
should support PD.
Let's say we have a router supporting 1 WAN and
Nobody even suggested that. For instance, if these addresses had a
lifetime (in the RFC4941 sense), they wouldn't be called stable in the
first place.
I suggest that you add a discussion of site renumbering considerations.
The problems described in draft-ietf-6renum-static-problem need
to
The concern is that we are still mainly ignoring the renumbering
problem, and in some years time this will be serious for users.
But if you add From the point of view of renumbering, these addresses
behave like RFC4941 addresses the point is covered.
... behave like RFC4862 addresses.
[...]
I briefly read into the 4rd draft, but it's not entirely clear to me
whether other solutions don't exist. Maybe there are other means to
get the context knowledge that this particular IPv6 address has a
special structure encoded somehow.
as a clarification of what has happened in
What, on an IPv6 host or router, cares about the g bit apart from the
code that uses an EUI-48 or EUI-64 to create an EID? What starts from
an EID and extracts from it an EUI-64/48 address, or in any other way
interprets the g flag in an EID?
u and g are a recurring theme. Apart from the
Also, is there any reason not to choose (for example)
FDFE:::-FDFE:::
which is near the existing anycast range ?
No objection that I can see.
Support for including this in the 6man answer.
I think this is better than making any assumption abut the u/g flags.
even
all,
the ADs have asked us to ensure that there are good review of documents in the
working group, prior to them being advanced to the IESG.
as a part of document last calls in the 6man working group, Bob and I want to
try
using volunteers and/or w.g. chair reviewers, that take specific
Remi,
[...]
To make assertions about IP addresses based on the EUI-64 is to impose
requirements that don't actually exist in IP. It's a little like saying that
concrete MUST (are required to) be grey because the rocks we use in it
happen to be grey; no I can have concrete of other colors
Remi,
To make assertions about IP addresses based on the EUI-64 is to impose
requirements that don't actually exist in IP. It's a little like saying
that concrete MUST (are required to) be grey because the rocks we use in
it happen to be grey; no I can have concrete of other colors if I
Remi,
there appears to be quite a lot of pushback in 6man against the use of u/g
bits as specified in the 4rd draft.
FUD, yes, but technically founded pushback that haven't been answered, no one
left AFAIK.
I can't parse the above.
For instance, in you own long list of doubts, you
Fernando,
General comments:
--
We do see the usefulness of a interface-id generation algorithm, that
results
in stable identifiers per IPv6 prefix, while not being derived from
link-layer
MAC addresses.
The mechanism proposed could be viewed as an modification of
Fernando, et al,
We have published a revision of our I-D entitled Security Implications
of IPv6 options of Type 10xx, about IPv6 smurf amplifiers.
The I-D is available at:
http://www.ietf.org/internet-drafts/draft-gont-6man-ipv6-smurf-amplifier-01.txt.
Any comments will be very
[...]
- If agreed on the principle, and if no one else volunteers, I can be
available to propose a draft to this effect.
Seems reasonable.
(e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
IIDs having u=g=1 is reserved. This leaves plenty of space for future
uses of
Brian,
- If agreed on the principle, and if no one else volunteers, I can be
available to propose a draft to this effect.
Seems reasonable.
(e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
IIDs having u=g=1 is reserved. This leaves plenty of space for future
uses of
Remi,
I still think we need to answer the question Brian raised.
should the interface-id have any encoded meaning?
That will not be done overnight. I've been thinking about it and
have some ideas about how to write a discussion draft, but it is
unfortuante to make the 4rd work queue behind
...@globis.net:
inline.
Ole Troan wrote:
Brian,
- If agreed on the principle, and if no one else volunteers, I can be
available to propose a draft to this effect.
Seems reasonable.
(e) With the 16-bit 4rd IID prefix, only 1/2^14 of the unused set of
IIDs having u=1 is reserved. This leaves
Remi,
I believe that the original question really was whether it makes
sense to reserve an unused IID range for 4rd.
A 4rd reserved range, for 4rd activation to never require IPv6
renumbering, has been for long in the specification studied in
Softwire.
But my understanding is that
Erik, Igor,
as part of doing the writeup to the IESG. do you know of any implementations or
plans for implementations
of impatient NUD?
cheers,
Ole
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests:
+1
If a better alternative is devised for 4rd, as Roland proposes here, then can
we deprecate the u/g bit usage? Seems to me that privacy addresses are
preferable anyway, if not DHCP or statically assigned ones, so any importance
assigned to u/g surely becomes a historical artifact?
design has been stabilized for long in Softwire.
- The question to 6man is ONLY whether the proposed reserved range is
compatible with the IPv6 addressing architecture.
Thanks,
RD
De : Ole Troan o...@cisco.com
Objet : Rép : Keeping the 4rd-range issue separate from the general u/g
Ron,
thanks for the reminder.
If the chairs were to initiate a last call, I would support this document.
Maybe the chairs can comment?
Bob and I will discuss progress on this document in our call next week.
Best regards,
Ole
while we are on the topic, and you made me re-read the document.
section 4:
issues with terminology. call a device that walks the extension header chain
something else than a router.
rfc2460 definition of a router; extension headers are not examined or
processed by any node along a packet's
.
Would the draft be more acceptable if we stated this as the motivation and
removed references to NAT64?
yes, I think that would help.
Best regards,
Ole
Ron
-Original Message-
From: Ole Troan [mailto:o...@cisco.com]
Sent: Wednesday
1 - 100 of 168 matches
Mail list logo
