Subject: [v6ops] Thinking about problems in IPv6-only networks

From: Fred Baker <[email-masked]>
Date: Fri, 17 Aug 2018 11:06:11 -0700

Ron and I just had our bi-weekly phone call, and identified a topic that might be interesting and useful. We'd like to invite a draft from people that are deploying IPv6-only networks or parts of networks identifying the problems they are experiencing that the IETF might be in a position to address. The objective, as always, is to solve problems preventing such a deployment in time for vendors and open source to provide solutions.
--------------------------------------------------------------------------------
Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
     Sun Tzu

---

From: Lee Howard <[email-masked]>
Date: Fri, 17 Aug 2018 14:23:02 -0400

Problems I've encountered (off the top of my head):

  * Documentation assumes/uses IPv4
  * Listeners only configured for IPv4
  * Software repos that are IPv4-only
  * CA/CRL/OCSP that are IPv4-only
  * VPN software that is unaware of IPv6, so client is split tunnel when
    on a dual-stack network
  * No IPv6 support in openssl (is there a better troubleshooting tool I
    should use?)
  * Mail is still a mess
  * Bugs in home gateways
  * Chicken-and-egg provisioning/OSS need to run IPv6, but routers and
    firewalls have to run IPv6 to get to them.

I've made it through most router configuration (I always have to tell 
engineers that router-id is an integer not an IPv4 address; it sure 
looks like an address; oh, and it has to be manually configured in an 
IPv6-only network).

That's all very operational; is that the sort of stuff you're thinking? 
If so, I'll go ahead and start a draft and see who else wants to 
contribute. Most of it is temporary (I hope) or related to other people 
not deploying, so I 'm not sure whether this is what you have in mind.

Lee

On 08/17/2018 02:06 PM, Fred Baker wrote:
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 17 Aug 2018 20:02:01 +0000

On 17 Aug 2018, at 18:06, Fred Baker wrote:

> Ron and I just had our bi-weekly phone call, and identified a topic 
> that might be interesting and useful. We'd like to invite a draft from 
> people that are deploying IPv6-only networks or parts of networks 
> identifying the problems they are experiencing that the IETF might be 
> in a position to address. The objective, as always, is to solve 
> problems preventing such a deployment in time for vendors and open 
> source to provide solutions.

(a) I think the IETF is the wrong place;  I gave a talk in 2011 at a BSD 
conference after I went v6-only, I saw talks at UKNOF (or UK IPv6 c. 
meeting), ..  I am sure the “NOG”s are doing similar.

(b) for the last 8 years it’s been working fantastic including a 
multi-site v6-only VPN;  bash your vendors, open bug reports, if not.

(c) the two major problem is “fear of breaking things” or “being 
ignorant to IPv6”  rather than just doing and dealing with it.

/bz

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Aug 2018 08:57:31 +1200

> meeting), ..  I am sure the “NOG”s are doing similar.

The wrong place for collecting info? Possibly.
The wrong place for fixing implementations? Certainly.
The wrong place for collating info, fixing standards and BCPs? I don't think so.
> multi-site v6-only VPN;  bash your vendors, open bug reports, if not.

Well, try setting a major hotel network to IPv6-only and see what happens...

> ignorant to IPv6”  rather than just doing and dealing with it.

I do agree with you (and Lee) that most of the issues are
implementation or deployment related. However, who besides the
IETF is going to do the job of collating information and figuring
out if any standards or BCPs are at fault or lacking?

    Brian

---

From: Lee Howard <[email-masked]>
Date: Fri, 17 Aug 2018 17:23:21 -0400

> The wrong place for collating info, fixing standards and BCPs? I don't think so.
Operational BCPs have a better home in BCOP.

> out if any standards or BCPs are at fault or lacking?

Will writing this draft  identify any faulty or lacking standards or 
BCPs that would not have been found and reported otherwise? Anyone who 
is testing IPv6-only systems or networks and who is on v6ops already 
knows how to say, "Hey, this doesn't look right."
Is anyone going to do more testing than they otherwise would have 
because of this document?
Are any bugs going to get reported that otherwise wouldn't have?

If implementations are buggy, we report them to the implementor. Sure, 
they usually ignore us and tell us IPv6 isn't important. Would that change?
If deployments are buggy, . . . well, that's a broken network. I know 
how to wring a vendor's neck.

If this is point-in-time advice that IPv6-only is frustrating for 
$ListOfReasons, okay, I'll work on it. That seems like 
operational/deployment advice, and is in charter. I don't think it has 
much utility beyond a point in time, though.

Or it could be a name-and-shame list. Not sure that's what we want.

Lee

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Fri, 17 Aug 2018 21:33:45 +0000

> out if any standards or BCPs are at fault or lacking?

People who swear over the RFC texts and think “if you had to implement 
that you’d never write that”.   Sadly that feedback loop is too late 
unless you want more instead of less text.

/bz

---

From: Tom Herbert <[email-masked]>
Date: Fri, 17 Aug 2018 14:55:51 -0700

> Ron and I just had our bi-weekly phone call, and identified a topic that might be interesting and useful. We'd like to invite a draft from people that are deploying IPv6-only networks or parts of n…

I believe that Facebook was one of the first major datacenter
operators to go IPv6-only. It was "bumpy", and the problems were well
documented like in
https://www.internetsociety.org/resources/deploy360/2014/case-study-facebook-moving-to-an-ipv6-only-internal-network/.
I don't know if they turned that into a draft.

Tom

---

From: "[email-masked]" <[email-masked]>
Date: Sat, 18 Aug 2018 09:01:21 +0800

Hi, Fred, 
I think this is a very good point. Actually we have done this work in our network and it is capable to IPv6-only access to mobile users in some area, algthough it is in the early stage .  If possible, I hope I can join this draft.
Thank you!

Chongfeng

[email-masked]
 
From: Fred Baker
Date: 2018-08-18 02:06
To: [email-masked] list
Subject: [v6ops] Thinking about problems in IPv6-only networks

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 17 Aug 2018 20:09:41 -0500

Hi Fred,

I will be happy to join, but first I think we need to clarify what is IPv6-only in the scope of this document/work ...

Are we talking about a network that in the "customer" LANs doesn't have ANY IPv4 and never connects to any "IPv4-only remote site".

Are the access links IPv6-only ? Or the LANs are IPv6 only, but the access links are dual-stack?

Or the LAN's don't have IPv4, but apps, running IPv6 can connect to remote "IPv4-only sites" (so the network or the access provider) has a NAT64 or equivalent mechanism?

I recall we tried to clarify this definition in a previous document, and I still see everybody reading different things ...

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de Fred Baker <[email-masked]>
Fecha: viernes, 17 de agosto de 2018, 13:06
Para: "[email-masked] list" <[email-masked]>
Asunto: [v6ops] Thinking about problems in IPv6-only networks

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 18 Aug 2018 14:30:01 +1200

> Operational BCPs have a better home in BCOP.

Yes, that dividing line is a judgment call. IMNSHO anything that
affects implementers is probably more effective in an RFC.
 
> Are any bugs going to get reported that otherwise wouldn't have?

I don't know, and I fear that the only way to find out is to try it.

> much utility beyond a point in time, though.

Agreed.
 
> Or it could be a name-and-shame list. Not sure that's what we want.

I'm fairly sure we don't want that.

   Brian

---

From: Alejandro Acosta <[email-masked]>
Date: Sat, 18 Aug 2018 00:39:41 -0400

good point

---

From: "Ackermann, Michael" <[email-masked]>
Date: Sat, 18 Aug 2018 14:39:14 +0000

Lee
This is good info.     I hope a related draft gets developed and would be happy to contribute if it does.
Thanks
Mike

From: v6ops <[email-masked]> On Behalf Of Lee Howard
Sent: Friday, August 17, 2018 2:23 PM
To: [email-masked]
Subject: Re: [v6ops] Thinking about problems in IPv6-only networks

  *   Documentation assumes/uses IPv4
  *   Listeners only configured for IPv4
  *   Software repos that are IPv4-only
  *   CA/CRL/OCSP that are IPv4-only
  *   VPN software that is unaware of IPv6, so client is split tunnel when on a dual-stack network
  *   No IPv6 support in openssl (is there a better troubleshooting tool I should use?)
  *   Mail is still a mess
  *   Bugs in home gateways
  *   Chicken-and-egg provisioning/OSS need to run IPv6, but routers and firewalls have to run IPv6 to get to them.

I've made it through most router configuration (I always have to tell engineers that router-id is an integer not an IPv4 address; it sure looks like an address; oh, and it has to be manually configured in an IPv6-only network).

That's all very operational; is that the sort of stuff you're thinking? If so, I'll go ahead and start a draft and see who else wants to contribute. Most of it is temporary (I hope) or related to other people not deploying, so I 'm not sure whether this is what you have in mind.
Lee

     Sun Tzu

v6ops mailing list

[email-masked]<mailto:[email-masked]>

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: Ca By <[email-masked]>
Date: Sat, 18 Aug 2018 08:18:20 -0700

On Fri, Aug 17, 2018 at 11:24 AM Lee Howard <[email-masked]> wrote:

>    - Documentation assumes/uses IPv4
>    - Listeners only configured for IPv4
>    - Software repos that are IPv4-only
>    - CA/CRL/OCSP that are IPv4-only
>    - VPN software that is unaware of IPv6, so client is split tunnel when
>    on a dual-stack network
>    - No IPv6 support in openssl (is there a better troubleshooting tool I
>    should use?)
>    - Mail is still a mess
>    - Bugs in home gateways
>    - Chicken-and-egg provisioning/OSS need to run IPv6, but routers and
Sounds challenging.  Twitter also does not work on ipv6-only.

In my world, ipv6-only Android and iOS have been relatively painless and
certainly achievable, and this experience has been repeated in other
networks too. Rogers in Canada recently moved to ipv6-only iOS

Going back to Jordi’s point, what does ipv6-only mean?  Certainly Android
and iOS have integrations with NAT64 that makes them work well on an
ipv6-only access network.  I once read Windows 10 has CLAT client, but i
have never used it myself.

So, maybe the draft needs to outline the obvious. Ipv6-only networks that
want to provide consumer internet service need an integration point such as
a B4 or a CLAT, which have both been deployed at scale for years, and thus
have a body of knowlege to justify a bcp. Second, perhaps a seperate draft,
outlines a catalog of services that require a B4 or CLAT and how to
minimize their use.  For me, i would be interested in hearing how the
ipv6-only enterprise networks that have been trumpeted at FB, Cisco and
Comcast are doing.

We should avoid the fruitless dicsussion of how many ipv6 angels can dance
on the head of an ipv4 pin.

>    -
> engineers that router-id is an integer not an IPv4 address; it sure looks
> like an address; oh, and it has to be manually configured in an IPv6-only
> network).
>
> That's all very operational; is that the sort of stuff you're thinking? If
> so, I'll go ahead and start a draft and see who else wants to contribute.
> Most of it is temporary (I hope) or related to other people not deploying,
> so I 'm not sure whether this is what you have in mind.
>
> Lee
>
>
> v6ops mailing [email-masked]://www.ietf.org/mailman/listinfo/v6ops
>
>

---

From: Fred Baker <[email-masked]>
Date: Sat, 18 Aug 2018 15:01:29 -0700

> On Aug 17, 2018, at 2:23 PM, Lee Howard <[email-masked]> wrote:
> 
> If this is point-in-time advice that IPv6-only is frustrating for $ListOfReasons, okay, I'll work on it. That seems like operational/deployment advice, and is in charter. I don't think it has much utility beyond a point in time, though.

That's pretty much what we had in mind. That said, we have been wrong before.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Sun, 19 Aug 2018 14:22:01 +0000

On 18 Aug 2018, at 15:18, Ca By wrote:

> minimize their use.

But don’t we have enough RFCs on these topics already?

> For me, i would be interested in hearing how the

Or Microsoft ..   but these things are all discusses at other places.
They have been and still are.  Presentations are online, slides available
to some degree.  Look at the country and intl IPv6 conferences, the *NOGs, ..
The IETF does not have to rehash all this, do we?

---

From: Fred Baker <[email-masked]>
Date: Sun, 19 Aug 2018 09:28:31 -0700

I think this is something the draft might discuss. To me, "IPv6-only" means that the object in question is using only IPv6. If it's an application, it doesn't have or can't use anything else. If it's a host, it doesn't have an IPv4 address, whether it can use one or not. If it's a network, only IPv6 is deployed in it. At whatever scale is under discussion, IPv4 is not a factor and IPv6 has replaced it.

Making it more complicated than that doesn't help, IMHO.

> On Aug 17, 2018, at 6:09 PM, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> Hi Fred,
> 

--------------------------------------------------------------------------------
The fact that there is a highway to hell and a stairway to heaven is an interesting comment on projected traffic volume...

---

From: Jen Linkova <[email-masked]>
Date: Mon, 20 Aug 2018 16:48:15 +1000

> Are the access links IPv6-only ? Or the LANs are IPv6 only, but the access links are dual-stack?

I'd read 'IPv6-only network' as a network  which only carries IPv6
packets. So if you are saying 'IPv6-only LAN' I'd expect
the LAN in question do not have any IPv4 addresses assigned (ex. IPv4
link-local). If you are saying 'IPv6-only backbone' I'd assume that
routers have only IPv6 addresses.
Obviously such a network might be connected to other IPv4-only or
dual-stack networks. Examples: IPv6-only LAN can be connected to
dual-stack backbone or ISP.

I suspect that confusion is caused by the fact that sometimes we
called a network 'IPv6-only' when only part of that network is
actually IPv6-only (e.g. instead of saying 'ISP X is deploying
IPv6-only network' we might want to say 'ISP X is deploying IPV6-only
backbone/access network'.

> Or the LAN's don't have IPv4, but apps, running IPv6 can connect to remote "IPv4-only sites" (so the network or the access provider) has a NAT64 or equivalent mechanism?

I do not believe we need to tie the IP level network capabilities with
what applications can or can not do.

DNS64, NAT64 and other mechanisms are add-ons to an IPv6 network
allowing devices to access IPv4 destinations, *if needed*. It's quite
possible that devices do not need such access at all, or only some
devices on such network need it.

-- 
SY, Jen Linkova aka Furry

---

From: Jen Linkova <[email-masked]>
Date: Mon, 20 Aug 2018 16:54:37 +1000

On Sat, Aug 18, 2018 at 4:06 AM Fred Baker <[email-masked]> wrote:
>
> Ron and I just had our bi-weekly phone call, and identified a topic that might be interesting and useful. We'd like to invite a draft from people that are deploying IPv6-only networks or parts of networks identifying the problems they are experiencing that the IETF might be in a position to address.

*A* draft? ;) Or multiple drafts? I'm not convinced that all problems
need to go to one draft because they might be of completely different
nature.
--
SY, Jen Linkova aka Furry

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 21 Aug 2018 12:14:01 +1200

> The IETF does not have to rehash all this, do we?

Well, first we need to know our objective. I suggest that our
objective should be to identify things that the IETF should
do to alleviate the alleged problems. Since what we can do
is write standards-track, BCP or informational RFCs, the real
question is: which of the alleged problems could in fact be fixed
by new RFC text?

I don't know how to do that except by making a list of the
alleged problems and checking off the ones that RFC text
could fix. Boring, no?

    Brian

---

From: Ole Troan <[email-masked]>
Date: Tue, 21 Aug 2018 11:41:51 +0200

> alleged problems and checking off the ones that RFC text

+1 emphasis on _new_.

Best regards,
Ole

---

From: Alejandro D'Egidio <[email-masked]>
Date: Tue, 21 Aug 2018 12:21:22 -0300 (ART)

Hello Fred,
First at all, I think it could be a good discussion and I would like to help with anything I can.
I think the "Ipv6-only networks" is too match general, but I think also it could be the intention, right?

So, from ISP point of view we normally talk about IPv6 networks thinking of final users (residential customers) o access networks but there are other parts:
-CORE: As we normally have a MPLS Network, we just transport IPv6 as a part of Internet "service" but we still have an IPv4 Core (IGP, MP-BGP, IDs, etc). Depending on devices and software releases we can do more or less things. Something very simple, in OSPFv3 router-id is IPv4
-Provisioning: We normally prepare the provisioning system to provide IPv6 to customers and CPEs but its internal infrastructure keeps in IPv4.
-Video: In the world of Video (headend) are using more and more Multicast but in IPv4, most of devices don't even have options for IPv6.
-Monitoring and workstations: I have seen some IPv6 implementations in ISPs to provide it to its customers without having IPv6 in their own PCs and monitoring systems. Firewalls and VPNs are also included.

Regards,
Alejandro

---

From: Lee Howard <[email-masked]>
Date: Tue, 21 Aug 2018 12:20:19 -0400

> question is: which of the alleged problems could in fact be fixed

That was exactly the charter of sunset4, which is in a coma from lack of 
work.
> alleged problems and checking off the ones that RFC text

I will boldly assert that there are no RFCs requiring updates in order 
to deploy IPv6-only.

I make that assertion not so much from complete confidence, but as a 
challenge to prove me wrong.

IPv6-only deployment suffers from scarce business drivers, buggy 
implementations, and vendor support. There's an enterprise 
"multi-homing" problem that I think has been addressed several ways. 
There's the interaction of fragmentation headers and DNSSec (or other 
apps using transport without session management, or anycast; see 
draft-ietf-intarea-frag-fragile).  I don't think there's more the IETF 
can do.

Lee

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Aug 2018 12:26:14 -0400

What's the state of SIP over IPv6 these days?

On Tue, Aug 21, 2018 at 12:20 PM, Lee Howard <[email-masked]> wrote:

> I will boldly assert that there are no RFCs requiring updates in order to
> deploy IPv6-only.
>
> implementations, and vendor support. There's an enterprise "multi-homing"
> problem that I think has been addressed several ways. There's the
> interaction of fragmentation headers and DNSSec (or other apps using
> transport without session management, or anycast; see

---

From: Fred Baker <[email-masked]>
Date: Tue, 21 Aug 2018 10:06:15 -0700

> On Aug 21, 2018, at 8:21 AM, Alejandro D'Egidio <[email-masked]> wrote:
> 
> Hello Fred,

It may be too general.

> -CORE: As we normally have a MPLS Network, we just transport IPv6 as a part of Internet "service" but we still have an IPv4 Core (IGP, MP-BGP, IDs, etc). Depending on devices and software releases…

Actually, no. RFC 5340 (OSPF for IPv6, aka OSPFv3) specifies that router ids and lsids remain 32 bits as in the IPv4 case, but does not specify that they are IPv4 addresses. Even in OSPFv2, many implementations use one of the IPv4 addresses of a system by default, but the protocol simply specifies a 32 bit number.

> -Monitoring and workstations: I have seen some IPv6 implementations in ISPs to provide it to its customers without having IPv6 in their own PCs and monitoring systems. Firewalls and VPNs are also i…

So, operationally, there is neither intention nor capability to turn IPv4 off except as a service. Close?

---

From: Lee Howard <[email-masked]>
Date: Tue, 21 Aug 2018 13:28:43 -0400

> What's the state of SIP over IPv6 these days?

It works. If you're communicating between address families, you need a 
B2BUA as a TrGW (back to back user agent as a translation gateway), 
which is statefully expensive.

I haven't personally implemented it, but I've worked with those who have.

Do you know of other gaps?

Lee

>
> On Tue, Aug 21, 2018 at 12:20 PM, Lee Howard <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>
>     That was exactly the charter of sunset4, which is in a coma from
>     lack of work.
>
>
>     I will boldly assert that there are no RFCs requiring updates in
>     order to deploy IPv6-only.
>
>     I make that assertion not so much from complete confidence, but as
>     a challenge to prove me wrong.
>
>     "multi-homing" problem that I think has been addressed several
>     ways. There's the interaction of fragmentation headers and DNSSec
>     (or other apps using transport without session management, or
>     anycast; see draft-ietf-intarea-frag-fragile).  I don't think
>     there's more the IETF can do.
>
>     Lee
>
>
>
>              Brian
>
>         [email-masked] <mailto:[email-masked]>
>         <https://www.ietf.org/mailman/listinfo/v6ops>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/v6ops>
>
>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Aug 2018 13:29:52 -0400

Nope, that's the big one for me.   I don't have a SIP provider that
supports IPv6.

On Tue, Aug 21, 2018 at 1:28 PM, Lee Howard <[email-masked]> wrote:

> B2BUA as a TrGW (back to back user agent as a translation gateway), which
> is statefully expensive.
>

---

From: David Farmer <[email-masked]>
Date: Tue, 21 Aug 2018 13:57:37 -0500

On Fri, Aug 17, 2018 at 8:09 PM, JORDI PALET MARTINEZ <
jordi.palet=[email-masked]> wrote:

> Hi Fred,
>
> I will be happy to join, but first I think we need to clarify what is
> IPv6-only in the scope of this document/work ...
>
> Are we talking about a network that in the "customer" LANs doesn't have
> ANY IPv4 and never connects to any "IPv4-only remote site".
>
> Or the LAN's don't have IPv4, but apps, running IPv6 can connect to remote
> "IPv4-only sites" (so the network or the access provider) has a NAT64 or
> equivalent mechanism?
>
> I recall we tried to clarify this definition in a previous document, and I
> still see everybody reading different things ...
>

I don't think there is a single answer to this question, it is context
dependent.

In an ISP context, since CE routers are fairly typical. I think the
IPv6-only designation means IPv6-only from the customer edge through the
ISP's backbone, to the ISP's internet edge.  Allowing IPv4 on the customer
LAN, probably with something like 464XLAT/CLAT in the CE router. With NAT64
occurring near the ISP Internet edge.

However, larger enterprises don't commonly have CE routers. Larger
enterprise access LANs frequently connect directly to enterprise backbone
routers or layer 3 switches that don't typically include features like
464XLAT/CLAT.  Again with NAT64 occurring near the enterprise Internet
edge. So at least in my opinion in the context of these larger enterprises,
the LAN is included in the IPv6-only designation and if there is
464XLAT/CLAT function, it needs to occur in the enterprise host itself or
it needs a bump-in-the-host. There is another option, but at least in my
enterprise environment it isn't practical, all applications could be IPv6
enabled. Whereas very small enterprises or SOHO environments will have a CE
router and the LAN may not matter in the IPv6-only designation.

Then again there are ISP environments without CE routers, like an IPv6-only
Public WiFi, in this case, the LAN is probably included in the IPv6-only
designation. And again, if there is a the 464XLAT/CLAT function, it needs
to occur in the host itself or the host needs a bump-in-the-host, or all
applications need to be IPv6 enabled.

So, I guess the question I have, as a network operator is, do most host
OSes either implement a 464XLAT/CLAT function or a bump-in-the-host or
require all applications to be IPv6 enabled? I'm not sure it is the IETF's
job to provide this information, but it will be useful if we expect
IPv6-only deployments to proceed. I'm not saying there can't be gaps, but
as a network operator, I need to understand what the gaps are before I can
proceed with production IPv6-only deployments.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Gert Doering <[email-masked]>
Date: Tue, 21 Aug 2018 21:16:27 +0200

Hi,

> What's the state of SIP over IPv6 these days?

At least one german access providers uses this, and it seems to work.

(Over here, an end user account is fairly often "native IPv6 and
DS-Lite for IPv4" these days, and the providers' own SIP stuff is 
done via IPv6.  AVM Fritz!Box, m-net.de)

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                      Vorstand: Sebastian v. Bomhard, Michael Emmer
Joseph-Dollinger-Bogen 14        Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                 HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444         USt-IdNr.: DE813185279

---

From: Jen Linkova <[email-masked]>
Date: Wed, 22 Aug 2018 09:14:27 +1000

> I will boldly assert that there are no RFCs requiring updates in order to

I'm afraid some RFCs might need clarifications (or one might call it
'guidance to vendors/implementors') to make sure IPv6-only
works as well (from end-user perspective) as dual-stack networks.

-- 
SY, Jen Linkova aka Furry who has spent significant amount of time
recently troubleshooting IPv6-only networks....

---

From: Jens Link <[email-masked]>
Date: Mon, 27 Aug 2018 10:19:16 +0200

>   * Software repos that are IPv4-only

I did a prensentation at the last RIPE Meeting about that[1]. I tried to
build Linux from Scratch on an IPv6 only host and then asked the people
not having IPv6 why.

After that I checked the homepage variable in the rpm spec files of a
current CentOS mirror. About 3/4 (out of ~1.000 hosts) was not
reachable via IPv6.

BTW: I've given up asking, using https://ipv6excuses.com/ takes way less
time and has the same results.

Jens
[1] https://ripe76.ripe.net/wp-content/uploads/presentations/146-we_dont_need_ipv6.pdf
-- 
----------------------------------------------------------------------------
| Foelderichstr. 40   | 13595 Berlin, Germany           | +49-151-18721264 |
| http://blog.quux.de | jabber: [email-masked]        | ---------------  | 
----------------------------------------------------------------------------

---

From: Jens Link <[email-masked]>
Date: Mon, 27 Aug 2018 10:10:49 +0200

> At least one german access providers uses this, and it seems to work.

In Germany I'm aware of sipgate running SIP over IPv6. After complaing
in their blog that all the (cable) providers are evil and doing some NAT
for IPv4. They got about 50 comments that they should run IPv6.

Jens

---

From: Tim Chown <[email-masked]>
Date: Tue, 28 Aug 2018 08:02:01 +0000

> On 27 Aug 2018, at 09:10, Jens Link <[email-masked]> wrote:
> 

I can remember running IPv6 SIP well over ten years ago, but that was with open source not commercial platforms.

In the UK, the first ISP that supported IPv6 has IPv6 SIP - https://aa.net.uk/kb-telecoms-voip.html

Tim

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 29 Aug 2018 19:02:14 +0000

> I will boldly assert that there are no RFCs requiring updates in order

I suggest both DHCPv6 and SLAAC to be enabled by default. Currently, RFC4861 recommends to disable DHCPv6 by default.

RFC4862 already mandates SLAAC by default. Section 5.5:
						"the processing described below MUST be
						enabled by default."
But, this should be changed:
	- RFC4861 section 6.2.1: AdvManagedFlag and AdvOtherConfigFlag: Default: FALSE
	==> Change 'O' bit default value to TRUE (AdvOtherConfigFlag: Default: TRUE).

 to allow hosts to be deployed and automatically configured (i.e. get IPv6 address and other configuration automatically) in any environment:
- DHCPv6 only environment (no config via RA and SLAAC can be disabled), or
- SLAAC only environment (no DHCPv6 config and DHCPv6 can be disabled), or
- DHCPv6 and SLAAC environment.
using the default settings.

With the current RFC4861 recommendation (AdvManagedFlag and AdvOtherConfigFlag: Default: FALSE), if DHCPv6 is disabled on hosts that are deployed in the network which configures hosts using DHCP (DHCPv6 only environment), the hosts will not work. Changing AdvOtherConfigFlag: Default: TRUE will allow hosts to assign SLLAC addresses and obtain the application configuration using stateless DHCPv6.

Regards,
Dusan.

> -----Original Message-----
> Sent: Tuesday, August 21, 2018 12:20 PM
> To: [email-masked]
> > https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=BFpWQw8bsuKp
> l1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=L_93
> AEOrqv1BjCUqko2-t_K-PeKX4KhbiWDsgHHxa90&s=Vb-
> HRMCpnYvnHdEL5pFK2yFbAmKqPU6Aq0RTxBtyiZw&e=
> 
> https://urldefense.proofpoint.com/v2/url?u=https-
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=BFpWQw8bsuKp
> l1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=L_93
> AEOrqv1BjCUqko2-t_K-PeKX4KhbiWDsgHHxa90&s=Vb-
> HRMCpnYvnHdEL5pFK2yFbAmKqPU6Aq0RTxBtyiZw&e=

---

From: Owen DeLong <[email-masked]>
Date: Wed, 29 Aug 2018 13:28:33 -0700

> On Aug 29, 2018, at 12:02 , Mudric, Dusan (Dusan) <[email-masked]> wrote:
> 

Why? Most environments have no need for DHCPv6 and setting the M flag on by default creates a situation
where no environment can be functional until the administrator takes one of the following actions:

	A.	Turn the M flag back off.
	B.	(arguably worse) Configure and manage a DHCPv6 server and set up forwarders as needed.

> using the default settings.

One of us is misunderstanding the situation here.

The flags you are talking about are, to the best of my knowledge, flags sent in a Router Advertisement.

Routers don’t do DHCPv6 by default, nor is there any rational default DHCP server address for them to automatically forward to.

As such, since configuration is required in order to make DHCPv6 functional, is it not also reasonable to require that the M and/or O
flag be set by the administrator if they are desired in the environment?

Simply turning on those flags by default will break things in environments that don’t have DHCPv6 servers and saves one line
of configuration effort for administrators that have DHCPv6 servers.

I do not see an advantage to doing so.

> With the current RFC4861 recommendation (AdvManagedFlag and AdvOtherConfigFlag: Default: FALSE), if DHCPv6 is disabled on hosts that are deployed in the network which configures hosts using DHCP (D…

Again, I think you’re looking at the wrong side of the equation here. These flags do not (if I understand things correctly) affect what is enabled or disabled on the host.

They control the defaults for how Routers construct Router Advertisements.

Owen

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 29 Aug 2018 20:37:22 +0000

> They control the defaults for how Routers construct Router Advertisements.

And default 'O' flag set to TRUE should enabled stateless DHCPv6 to obtain configuration for hosts.

> 	A.	Turn the M flag back off.

Why the hosts will be unfunctional when 'M' or 'O' is set by default to TRUE?

Thanks,
Dusan

> From: Owen DeLong <[email-masked]>
> Sent: Wednesday, August 29, 2018 4:29 PM
> To: Mudric, Dusan (Dusan) <[email-masked]>
> Cc: Lee Howard <[email-masked]>; [email-masked]
> > I suggest both DHCPv6 and SLAAC to be enabled by default. Currently,
> RFC4861 recommends to disable DHCPv6 by default.
> >
> > to allow hosts to be deployed and automatically configured (i.e. get IPv6
> address and other configuration automatically) in any environment:
> Routers don’t do DHCPv6 by default, nor is there any rational default DHCP
> server address for them to automatically forward to.
> 
> As such, since configuration is required in order to make DHCPv6 functional,
> is it not also reasonable to require that the M and/or O
> Simply turning on those flags by default will break things in environments
> that don’t have DHCPv6 servers and saves one line
> > With the current RFC4861 recommendation (AdvManagedFlag and
> AdvOtherConfigFlag: Default: FALSE), if DHCPv6 is disabled on hosts that are
> deployed in the network which configures hosts using DHCP (DHCPv6 only
> environment), the hosts will not work. Changing AdvOtherConfigFlag:
> Default: TRUE will allow hosts to assign SLLAC addresses and obtain the
> application configuration using stateless DHCPv6.
> 
> Again, I think you’re looking at the wrong side of the equation here. These
> flags do not (if I understand things correctly) affect what is enabled or
> disabled on the host.
> 
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIFaQ&c=BFpWQw8bsuKpl
> 1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=BOR
> Zg0Rb0T0jfrwIGlL4oqsMvG-
> LGKPsVBE_hxP3IHM&s=U87fGGyH3LCov6T8ll30k4B05XV5GPhABlFEUi7lbWU
> &e=

---

From: David Farmer <[email-masked]>
Date: Wed, 29 Aug 2018 15:52:46 -0500

> And default 'O' flag set to TRUE should enabled stateless DHCPv6 to obtain

Only if there is, in fact, a DHCPv6 server and it is configured with
appropriate information.  Maybe you wish to recommend net operators deploy
DHCPv6, but change the default for the O flag in RAs is more that.

While I could be sympathetic to recommendations to provide DHCPv6 servers
on networks. However, changing the defaults for the M or O flags is not
something I can support.  If I provide a DHCPv6 server then it is my job to
set the flags appropriately in the RA. If I don't provide a DHCPv6 I should
not have to do anything. This is how the defaults for the M and O flag are
currently set.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 30 Aug 2018 10:24:07 +1200

> not have to do anything. This is how the defaults for the M and O flag are

Exactly. Working out of the box on an unmanaged network has always been
a goal for IPv6, even back when it was called IPng. The defaults are
set appropriately for that goal.

     Brian

---

From: George Michaelson <[email-masked]>
Date: Thu, 30 Aug 2018 08:41:50 +1000

despite having stood up at a microphone and accused Brian of
propagating 'the evil bit' again, I actually think an advisory 'this
is a v6 only managed network' is a good idea. It would allow people to
write code which does:

test if v6only, in getting your v6 bindings:

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Aug 2018 11:23:16 -0700

> On Aug 29, 2018, at 13:37 , Mudric, Dusan (Dusan) <[email-masked]> wrote:
> 

Only if there’s a DHCP server to provide the “Other” information.

If you’re setting up a DHCPv6 server, then turn the O and/or M bits on in your RAs as appropriate.

If you’re not setting one up, you shouldn’t have to change your RA flags just to tell it that you didn’t do so.

> Why the hosts will be unfunctional when 'M' or 'O' is set by default to TRUE?

Because if you didn’t set up a DHCP server and you set the M flag, the host will (if it is doing as it should)
not get an address via SLAAC and go hunting for one from the non-existent DHCPv6 server.

Have you tried any of this in a DHCP-less environment, or are you just assuming blindly that everyone
needs DHCPv6 and therefore it should always be enabled by default?

I’m running just fine on my IPv6-only networks here WITHOUT any DHCPv6 server.

If my routers switched to M+O set on RAs by default, I’d have to go in and change that for my network to keep
functioning.

Owen

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 30 Aug 2018 19:26:26 +0000

> a goal for IPv6,
I expected plug-and-play, or unmanaged network, means devices deployed to those networks should work based on the network defaults. If DHCPv6 is added to the network, 'O' flag needs to be set. That means managing the network.

> > If I don't provide a DHCPv6 I should
> > not have to do anything.
Right. If nothing is added to the network, there is no need to change the network configuration. But that is not the point. Plug-and-play is used when something is added to the network. There should not be a need to change 'O' bit when DHCPv6 server and DHCPv6 capable hosts are added to the network. And, if there are no DHCPv6 servers and DHCPv6 capable hosts in that network, sending 'O'=TRUE will not impact  the network.

Dusan

> From: Brian E Carpenter <[email-masked]>
> Sent: Wednesday, August 29, 2018 6:24 PM
> To: David Farmer <[email-masked]>; Mudric, Dusan (Dusan)
> <[email-masked]>
> Cc: [email-masked]
> >> And default 'O' flag set to TRUE should enabled stateless DHCPv6 to
> obtain
> >> configuration for hosts.
> >
> >

---

From: Owen DeLong <[email-masked]>
Date: Thu, 30 Aug 2018 17:17:05 -0700

> Right. If nothing is added to the network, there is no need to change the network configuration. But that is not the point. Plug-and-play is used when something is added to the network. There shoul…

You are badly mistaken. 

The O flag will cause hosts to seek information from a DHCPv6 server, hanging (possibly indefinitely) until that information is received. If there is no DHCPv6 server available to provide that information, you have now broken the network by changing the O flag without any reason to do so. 

Owen

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Fri, 31 Aug 2018 01:23:14 +0000

Actually, no. RFC 5340 (OSPF for IPv6, aka OSPFv3) specifies that router ids and lsids remain 32 bits as in the IPv4 case, but does not specify that they are IPv4 addresses.

Ditto. And Same behavior for BGP and LDP as well.
https://tools.ietf.org/html/rfc7552#section-4

Cheers,
Rajiv Asati
Distinguished Engineer, Cisco Services

On Aug 21, 2018, at 1:10 PM, Fred Baker <[email-masked]<mailto:[email-masked]>> wrote:

On Aug 21, 2018, at 8:21 AM, Alejandro D'Egidio <[email-masked]<mailto:[email-masked]>> wrote:

Hello Fred,

It may be too general.

Regards,
Alejandro

----- Mensaje original -----
De: "Fred Baker" <[email-masked]<mailto:[email-masked]>>
Para: "JORDI PALET MARTINEZ" <[email-masked]<mailto:[email-masked]>>
CC: "[email-masked]<mailto:[email-masked]> list" <[email-masked]<mailto:[email-masked]>>
Enviados: Domingo, 19 de Agosto 2018 13:28:31
Asunto: Re: [v6ops] Thinking about problems in IPv6-only networks

On Aug 17, 2018, at 6:09 PM, JORDI PALET MARTINEZ <[email-masked]<mailto:[email-masked]>> wrote:

Hi Fred,

Regards,
Jordi

---

From: Lee Howard <[email-masked]>
Date: Fri, 31 Aug 2018 09:47:31 -0400

> I expected plug-and-play, or unmanaged network, means devices deployed to those networks should work based on the network defaults. If DHCPv6 is added to the network, 'O' flag needs to be set. That…

An "unmanaged network" that is "based on the network defaults" sounds 
like it's in conflict with a server being "added to the network."

The M bit means there are addresses available via DHCPv6. It doesn't 
mean you have to use them.
The O bit means there is other configuration information available via 
DHCPv6. It is redundant if the M bit is set.
Neither requires a device to pay attention to them.

> Right. If nothing is added to the network, there is no need to change the network configuration. But that is not the point. Plug-and-play is used when something is added to the network. There shoul…

How does a router (a thing sending RAs) know a DHCPv6 server has been 
added to the network?
Even if a router is configured as a DHCPv6 relay, how does it know 
whether the M and/or O bits apply? That is, how does it know whether the 
DHCPv6 server is supplying addresses (M bit), or no addresses but 
DNS/NTP/other configuration (O bit)? (If the M bit is set, O is implied, 
per rfc4861).

You could require DHCPv6 snooping, but it's several layers of logic to 
compare what the client requests vs. what the response is. And to revise 
RAs based on changing DHCPv6 configurations. If the router *is* the 
DHCPv6 server, the logic is much simpler.

I'm content to say that if you add a server to provide network layer 
information, you are managing the network, and are therefore overriding 
defaults and are expected to manage the network. Essentially, the M bit.

Lee

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Fri, 31 Aug 2018 20:21:02 +0000

> The O flag will cause hosts to seek information from a DHCPv6 server,
> hanging (possibly indefinitely) until that information is received. If there is no
> DHCPv6 server available to provide that information, you have now broken
> the network by changing the O flag without any reason to do so.

Possible but it is not required, by any standard that I know about, that applications should wait indefinitely for DHCPv6 server response.

Dusan

> Sent: Thursday, August 30, 2018 8:17 PM
> Cc: Brian E Carpenter <[email-masked]>; David Farmer
> <[email-masked]>; [email-masked]
> > I expected plug-and-play, or unmanaged network, means devices
> deployed to those networks should work based on the network defaults. If
> DHCPv6 is added to the network, 'O' flag needs to be set. That means
> managing the network.
> >
> > Right. If nothing is added to the network, there is no need to change the
> network configuration. But that is not the point. Plug-and-play is used when
> something is added to the network. There should not be a need to change
> 'O' bit when DHCPv6 server and DHCPv6 capable hosts are added to the
> network. And, if there are no DHCPv6 servers and DHCPv6 capable hosts in
> that network, sending 'O'=TRUE will not impact  the network.
> 
> You are badly mistaken.
> 
> The O flag will cause hosts to seek information from a DHCPv6 server,
> hanging (possibly indefinitely) until that information is received. If there is no
> DHCPv6 server available to provide that information, you have now broken
> the network by changing the O flag without any reason to do so.
> 
> Owen
> 
> >
> > Dusan
> >
> 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIFAg&c=BFpWQw8bsuKpl
> 1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=7MH
> tvme6nAWYF4uDMH3gO_auo_qxpA8VsctyigS3New&s=UAR1vCzZ7eYHUKdgl
> xensNPphQb9IEool0hz1ozKIFs&e=

---

From: Simon Hobson <[email-masked]>
Date: Fri, 31 Aug 2018 21:52:52 +0100

Lee Howard <[email-masked]> wrote:

> An "unmanaged network" that is "based on the network defaults" sounds like it's in conflict with a server being "added to the network."

Not really. If you add a SERVER (such as DHCP6) then you are implicitly making it a managed network. At that point, you also take on responsibility for configuring the network as such - ie setting the M and/or O flags in the RAs.

> The M bit means there are addresses available via DHCPv6. It doesn't mean you have to use them.
> The O bit means there is other configuration information available via DHCPv6. It is redundant if the M bit is set.

I may be wrong, but I was under the impression that if the M bit is set, then the client is required to use DHCP to configure address(es) and not auto-configure. Thus if the M bit is set and there is no DHCP server, clients simply will not work.

None of this is inconsistent. An unmanaged network means that someone has thrown it together, accepting the default settings for RAs etc - and with some expectation that the router will get a working config (suitable prefix assignment) from upstream. Thus an unskilled person can put together a basic network with some expectation of "it just works" - much as happens when a user gets the ISP supplied router which uses something like TR069 to automatically get the required config and within a short time of plugging it in, give the user a working internet connection and LAN.

> How does a router (a thing sending RAs) know a DHCPv6 server has been added to the network?

Because the network administrator tells it. If there's a DHCP server, then it's not a basic unmanaged network. If it's managed then there's an admin responsible for it.

It would be possible for a router manufacturer to obfuscate this by providing a suitable GUI to configure and enable a DHCP server, and as a side effect, turn on the M and/or O bits in the RAs issued by **that router**. That would be OK for small routers (SOHO) where typically there is only the one router and one internet connection.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 1 Sep 2018 10:08:40 +1200

> It would be possible for a router manufacturer to obfuscate this by providing a suitable GUI to configure and enable a DHCP server, and as a side effect, turn on the M and/or O bits in the RAs issu…

Maybe, but homenet renders this obsolete. For now, SLAAC is necessary and sufficient for single-router SOHOs.

   Brian

---

From: Mark Smith <[email-masked]>
Date: Sat, 1 Sep 2018 09:21:45 +1000

On Sat., 1 Sep. 2018, 06:53 Simon Hobson, <[email-masked]> wrote:

> Not really. If you add a SERVER (such as DHCP6) then you are implicitly
> making it a managed network. At that point, you also take on responsibility
> for configuring the network as such - ie setting the M and/or O flags in
> the RAs.
>
> I may be wrong, but I was under the impression that if the M bit is set,
> then the client is required to use DHCP to configure address(es) and not
> auto-configure. Thus if the M bit is set and there is no DHCP server,
> clients simply will not work.
>

The signal to use SLAAC is one or more PIOs in the RA with the A bit set.

SLAAC and stateful DHCPv6 can coexist, and they're optional, in the sense
that the host can choose to use either or both. It is up to the host.

The only way to enforce the use of one of them is to only provide that as
the single method. (And even then if you think forcing stateful DHCPv6
means there is a database of all addresses, it won't contain statically
assigned ones.)

OpenWRT enables both by default, and a host that supports both SLAAC and
DHCPv6 e.g. Fedora Linux, will get addresses using both. (And compromises
SLAAC privacy addresses by limiting the stateful DHCPv6 address range to
the same as the IPv4 pool range size.)

So stateful DHCPv6 or not by itself is not a absolute statement of it being
a managed network or not.

> None of this is inconsistent. An unmanaged network means that someone has
> thrown it together, accepting the default settings for RAs etc - and with
> some expectation that the router will get a working config (suitable prefix
> assignment) from upstream. Thus an unskilled person can put together a
> basic network with some expectation of "it just works" - much as happens
> when a user gets the ISP supplied router which uses something like TR069 to
> automatically get the required config and within a short time of plugging
> it in, give the user a working internet connection and LAN.
>
> Because the network administrator tells it. If there's a DHCP server, then
> it's not a basic unmanaged network. If it's managed then there's an admin
> responsible for it.
>
> It would be possible for a router manufacturer to obfuscate this by
> providing a suitable GUI to configure and enable a DHCP server, and as a
> side effect, turn on the M and/or O bits in the RAs issued by **that
> router**. That would be OK for small routers (SOHO) where typically there
> is only the one router and one internet connection.
>

---

From: Owen DeLong <[email-masked]>
Date: Fri, 31 Aug 2018 20:17:31 -0700

> On Aug 31, 2018, at 13:21 , Mudric, Dusan (Dusan) <[email-masked]> wrote:
> 

Whether it’s required or not, it _IS_ the actual implementation in a number of existing systems.

SO… Changing the default value in this way breaks a lot of stuff that already exists. I’m not saying we should never
do that, but there certainly needs to be a compelling reason to do so or we shouldn’t do it.

So far, you have yet to provide anything remotely resembling a compelling reason.

Owen

>> From: Owen DeLong <[email-masked] <mailto:[email-masked]>>
>> To: Mudric, Dusan (Dusan) <[email-masked] <mailto:[email-masked]>>
>> Cc: Brian E Carpenter <[email-masked] <mailto:[email-masked]>>; David Farmer
>> <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>>> https://urldefense.proofpoint.com/v2/url?u=https- <https://urldefense.proofpoint.com/v2/url?u=https->

---

From: Owen DeLong <[email-masked]>
Date: Fri, 31 Aug 2018 20:22:55 -0700

> On Aug 31, 2018, at 13:52 , Simon Hobson <[email-masked]> wrote:
> 

My understanding was that there’s an exception for clients which don’t support DHCPv6 (which is, after all, optional).

> None of this is inconsistent. An unmanaged network means that someone has thrown it together, accepting the default settings for RAs etc - and with some expectation that the router will get a worki…

Well… Actually, an unmanaged network can still involve some manual configuration of the router insofar as the M bit definition of managed or not would mean it.

Most of my unmanaged IPv6-only networks do have manually configured router interfaces, and, in some cases, manually configured host addresses as well.

> Because the network administrator tells it. If there's a DHCP server, then it's not a basic unmanaged network. If it's managed then there's an admin responsible for it.

You guys are seeming to disagree while actually agreeing. Lee's response was aimed at Dusan’s desire to make O=1 the default for RAs unless the administrator deliberately turns it off on the router.

> It would be possible for a router manufacturer to obfuscate this by providing a suitable GUI to configure and enable a DHCP server, and as a side effect, turn on the M and/or O bits in the RAs issu…

Sure, nothing at all wrong with that. However, I don’t think anyone is disputing this.

Owen