Subject: [mif] DNS server selection issue #2: Different default namespaces

From: <[email-masked]>
Date: Thu, 11 Nov 2010 03:28:34 +0100

Hi,

In the meeting there was consideration that any address resolved via DNS may be interface specific. For example, if the returned address depends on the perceived geolocation of the requester.

In my opinion that problems is not about DNS SERVER selection, see charter:
---
a specification for describing a way for a network to communicate to nodes information required to perform advanced DNS server selection at name resolution request granularity in scenarios involving multiple namespaces.
---

The DNS server selection draft is about selecting DNS server. Now if the resolved addresses actually needs to be sent over the interface they were learned on, is that actually a routing problem? The host routing should know to send packets to those addresses over right interfaces?

I don't either know how to solve this by any other way than instantiating host specific route for each IP address learned with DNS.

Best regards,

Teemu

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Nov 2010 18:35:47 -0800

On Nov 11, 2010, at 10:28 AM, <[email-masked]> wrote:
> I don’t either know how to solve this by any other way than instantiating host specific route for each IP address learned with DNS.

IOW this problem and the API problem are intertwined.

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 03:42:19 +0100

So you agree this problem is not DNS server selection problem?

For DNS server selection problem application support cannot be assumed. E.g. in case of CPE implementing DNS proxy, that selects DNS server for the host behind CPE, the host and its applications are unaware of DNS server selection taking place.

> -----Original Message-----
> From: ext Ted Lemon [mailto:[email-masked]]
> Sent: 11. marraskuuta 2010 10:36
> To: Savolainen Teemu (Nokia-MS/Tampere)
> Cc: [email-masked]
> Subject: Re: [mif] DNS server selection issue #2: Different default
> namespaces
> 
> > The DNS server selection draft is about selecting DNS server. Now if
> the resolved addresses actually needs to be sent over the interface
> they were learned on, is that actually a routing problem? The host
> routing should know to send packets to those addresses over right
> interfaces?
> >
> > I don't either know how to solve this by any other way than
> instantiating host specific route for each IP address learned with DNS.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Nov 2010 18:59:33 -0800

> So you agree this problem is not DNS server selection problem?

My specific comment was simply that you can't solve this problem and the API problem in isolation--you have to consider both in order to come up with a good solution.   Since I don't think we should be selecting DNS servers, I suppose you could argue that I agree that this is not a server selection problem, but I suspect that's not what you meant.

> For DNS server selection problem application support cannot be assumed. E.g. in case of CPE implementing DNS proxy, that selects DNS server for the host behind CPE, the host and its applications ar…

Yes, this is a serious problem.   Another reason why DNSSEC is necessary, IMHO.   If you use DNSSEC, the proxy can prevent you from connecting by forging answers, but if it forwards data that validates, even if it comes from multiple sources, there's no problem.

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 04:22:11 +0100

> My specific comment was simply that you can't solve this problem and
> the API problem in isolation--you have to consider both in order to
> come up with a good solution.   Since I don't think we should be
> selecting DNS servers, I suppose you could argue that I agree that this
> is not a server selection problem, but I suspect that's not what you
> meant.

It was what I meant, I want this work proceed and hence I want to be clear what comments require changes to DNS server selection draft and what needs to be addressed elsewhere.

Hence it seems the "different default namespaces" would not necessarily be part of the DNS server select draft? However, the draft could include a note that the responses may not be global if they *seem to be'.

For solutions, the application could bind itself to an interface (via the API), or there could be host specific routes for each DNS response. But is that really feasible?
 
> > For DNS server selection problem application support cannot be
> assumed. E.g. in case of CPE implementing DNS proxy, that selects DNS
> server for the host behind CPE, the host and its applications are
> unaware of DNS server selection taking place.
> 
> Yes, this is a serious problem.   Another reason why DNSSEC is
> necessary, IMHO.   If you use DNSSEC, the proxy can prevent you from
> connecting by forging answers, but if it forwards data that validates,
> even if it comes from multiple sources, there's no problem.

We don't agree against DNSSEC here:) The proxy there would not modify queries/replies, just forward them to different recursive DNS servers.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Nov 2010 20:15:30 -0800

The fundamental disconnect that leaves me not liking this solution is that I think it's not possible to get definitive information from multiple sources.   Just because the provider on interface A says something is true doesn't mean that it is true.   Just because the provider on interface B says something that's different doesn't mean that it's wrong.

So the only solution that appeals to me is the one where the device is responsible for making the decision.   Trusting advice from upstream, unless it's in some way provably definitive, is not something I think is valid.

The only real clue you have as to what the right thing to do is is what works.   If I try to connect using information provided by provider A, and my SSH key matches or SSL cert matches, then the information is correct.   If I try to connect using information from provider B, and the SSL cert is wrong or the ssh host key is wrong, then the information is incorrect.

It seems to me that you are trying to address the case where the information being provided conflicts but is correct.   That is, the information on interface A for www.corporation.com is correct, but refers to the public site.   The information on interface B for www.corporation.com is also correct, but refers to the private site.

I agree that your draft solves this problem.   I agree that it's a real problem.   My objection to your draft is that there are many ways for information from multiple providers to conflict, and only a relatively few of them fall into the pattern that your draft is intended to address.   Your draft fails to address problems that fall into other patterns, and in addition it creates new problems.

A solution where the client makes its own choices will fail in some cases.   Your solution will also fail in some different set of cases.   The client-based solution is correct, although in some cases suboptimal.   Your solution is correct, and in some cases suboptimal.   So I am arguing for the correct solution.

Anything you can do to trim away failure modes for your solution will make me object to it less.   I don't object in principle to solving the problem you've described.   I just object to the side effects of your solution.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Nov 2010 20:52:48 -0800

> A solution where the client makes its own choices will fail in some cases.   Your solution will also fail in some different set of cases.   The client-based solution is correct, although in some ca…

Er, I meant to say that your solution is incorrect.   To be clear, I mean incorrect in the sense of "adds new technology to support brokenness," not "completely, horribly awful."

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 06:51:39 +0100

> > A solution where the client makes its own choices will fail in some
> cases.   Your solution will also fail in some different set of cases.
> The client-based solution is correct, although in some cases
> suboptimal.   Your solution is correct, and in some cases suboptimal.
> So I am arguing for the correct solution.
> 
> Er, I meant to say that your solution is incorrect.   To be clear, I
> mean incorrect in the sense of "adds new technology to support
> brokenness," not "completely, horribly awful."

What is IETF but full of tools that support brokenness (think about NAT traversal toolbox and various tunneling tools we develop to support continuous brokenness of NATted IPv4 Internet - and so on).

The brokenness is often also a point of view (as is case with NATs).

>From my point of view, my solution is a tool that helps nodes in the deployments where your brokenness is a desired feature.

	Teemu

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 06:47:26 +0100

> So the only solution that appeals to me is the one where the device is
> responsible for making the decision.   Trusting advice from upstream,
> unless it's in some way provably definitive, is not something I think
> is valid.

What if you look from the angle that the advice this tool provides is a hint - the node should first ask the DNS information from the DNS server that advertises itself as a "friend", but if that "friend" fails to provide (positive?) response your DNSSEC validates, then go talk to next in line. Host in control, but with hints it usually goes to talk to right party. Hence we could have fallback solution described. I'll see how it could look in the draft. 

> The only real clue you have as to what the right thing to do is is what
> works.   If I try to connect using information provided by provider A,
> and my SSH key matches or SSL cert matches, then the information is
> correct.   If I try to connect using information from provider B, and
> the SSL cert is wrong or the ssh host key is wrong, then the
> information is incorrect.

You would like to have collection of IPv4 and IPv6 addresses (asked from all configured name servers) delivered to your SSL client in preference order?

> It seems to me that you are trying to address the case where the
> information being provided conflicts but is correct.   That is, the

No, the main case is where from wrong interface we get NX or no reply. i.e. the case where positive response can be received only if asked from specific DNS server.

> information on interface A for www.corporation.com is correct, but
> refers to the public site.   The information on interface B for
> www.corporation.com is also correct, but refers to the private site.

That is secondary case. In that case both would validate with DNSSEC, but the person connected to intranet and internet *likely*, but not necessarily, is trying to access the internal side of the corporate webpage (in this likely case my solution helps choose correctly, or at least consistently - instead of "randomly"). Overloading FQDN with two or more services creates a problem that cannot be solved without knowing which service user wants to access: asking user do you want to go this or that way (very much resembling handset experience where handset asks do you want to connect via  VPN/WiFi/3G, and that people don't usually want to see). Hence full solution for this problem in my opinion is out of scope for MIF.

> I agree that your draft solves this problem.   I agree that it's a real
> problem.   My objection to your draft is that there are many ways for
> information from multiple providers to conflict, and only a relatively

There should be only limited ways for conflict in operation: providers MUST only advertise specific names for really specific names. Not for example things like most.popular.interent.site.com. 

> So I am arguing for the correct solution.

A merged solution perhaps: follow what is instructed, but use DNSSEC to ensure forgeries are avoided?

> Anything you can do to trim away failure modes for your solution will
> make me object to it less.   I don't object in principle to solving the
> problem you've described.   I just object to the side effects of your
> solution.

Ok, I'll do my best to modify the draft to be more acceptable for you as well.

Teemu

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Nov 2010 22:06:42 -0800

> No, the main case is where from wrong interface we get NX or no reply. i.e. the case where positive response can be received only if asked from specific DNS server.

The BBF liaison doc specifies a solution to this that's different: don't return a negative response until you've heard from both servers.   If this is your primary use case, what is wrong with the BBF solution?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 10 Nov 2010 22:29:55 -0800

> From my point of view, my solution is a tool that helps nodes in the deployments where your brokenness is a desired feature.

Right, but suppose I asked you to weld a snowplow to your car because sometimes it snows, and you might need it.   I'm sure you would agree that sometimes it snows, but you might worry that the snowplow would injure people, so it would be better if it were only there when it was needed, and not at all times.

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 08:02:24 +0100

> The BBF liaison doc specifies a solution to this that's different:
> don't return a negative response until you've heard from both servers.
> If this is your primary use case, what is wrong with the BBF solution?

They definitely don't want CPEs to send queries to all uplink VLANs. I'll let my colleagues answer this in more detail (if it indeed was not clear from BBF doc - it's a while I read it).

One detail I forgot to mention to you earlier: don't you think there is a security risk on revealing all your private names to DNS servers of all your interfaces?

I mean if I would somehow get my IT department to allow split tunneling on the VPN, I doubt they would like my computer to let IETF DNS server know all the intranet names I'm connecting to...

Best regards,

Teemu

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 08:34:55 +0100

> > From my point of view, my solution is a tool that helps nodes in the
> deployments where your brokenness is a desired feature.
> 
> Right, but suppose I asked you to weld a snowplow to your car because
> sometimes it snows, and you might need it.   I'm sure you would agree
> that sometimes it snows, but you might worry that the snowplow would
> injure people, so it would be better if it were only there when it was
> needed, and not at all times.

I'm sure this feature will be picked up by vendors only when justified by a business case (when the snowplow seems like useful thing to have). While some vendors work in the Sunny California, some vendors do business solely in the Antarctica:)

	Teemu

---

From: Haruhiko Nishida <[email-masked]>
Date: Thu, 11 Nov 2010 16:23:14 +0800

I totally agree that 

- there is no general solution
- decisions is always host's responsibility

Teemu and us shows some possible (or existing) use cases and (as you agreed)
the draft will help these cases.

What I'm not sure is whether you try to specify

- there is a better solution

or

- This draft is harmful in "this" use case.

The fist case, we can discuss on that solution. Later case, we will try to make our draft
mostly harmless, or less harmful in the case. Please let us know your thought.

-- Haru Nishida, NTT
 
On 2010/11/11, at 12:15, Ted Lemon wrote:

> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Nov 2010 00:29:03 -0800

> - This draft is harmful in "this" use case.

What I am saying is that the draft is useful in its intended use case, but harmful in other cases.

---

From: Haruhiko Nishida <[email-masked]>
Date: Thu, 11 Nov 2010 16:36:05 +0800

Thanks. Then will you let me know what is the harmful cases?

-- Haru

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Nov 2010 00:46:01 -0800

> Thanks. Then will you let me know what is the harmful cases?

There are two cases, one where one provider gives the client information that causes it to act against the interests of the owner of the mif node in the sense of using the wrong network for access, and the other where an attacker tricks the client into sending messages for a particular subdomain through it, while leaving the rest of the DNS service untouched.

Because there is no mechanism for authenticating or authorizing this option, there is no way to prevent this from happening.

---

From: Haruhiko Nishida <[email-masked]>
Date: Thu, 11 Nov 2010 16:58:52 +0800

Thanks again. We will think on them.

-- Haru

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Nov 2010 01:38:22 -0800

> They definitely don't want CPEs to send queries to all uplink VLANs. I'll let my colleagues answer this in more detail (if it indeed was not clear from BBF doc - it's a while I read it).

It isn't clear, no.

> I mean if I would somehow get my IT department to allow split tunneling on the VPN, I doubt they would like my computer to let IETF DNS server know all the intranet names I'm connecting to...

Indeed, in practice if your IT department cares at all about information leakage, particularly on that level, then they have to have a policy where everything is sucked through the tunnel.   In that case, MIF isn't involved.      I really don't think that particular problem is a MIF problem, because the solutions we're talking about provide no guarantee against information leakage of this type.

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 10:53:23 +0100

Hi,

I made some changes and posted a quick -05 http://www.ietf.org/id/draft-savolainen-mif-dns-server-selection-05.txt with things I had in my mind at this point.

Inline:

> There are two cases, one where one provider gives the client
> information that causes it to act against the interests of the owner of
> the mif node in the sense of using the wrong network for access, and

But then elsewhere people say network knows always better:) I'm confused of IETF:)

The user can fallback to use single interface. 

> the other where an attacker tricks the client into sending messages for
> a particular subdomain through it, while leaving the rest of the DNS
> service untouched.

The latest draft now recommends using DNSSEC to validate responses. Of course attacker can still *route* packets (and cause user to go to external side of www.corporation.com instead of internal?-)

> Because there is no mechanism for authenticating or authorizing this
> option, there is no way to prevent this from happening.

In some scenarios the uplinks are always trusted (BBF). Sometimes you can administratively limit which interfaces to trust.

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 11:20:06 +0100

Ted,

>From your point of view, are the RFC4191 and the new DHCPv6 route option also dangerous? 

I mean, if the host should send DNS queries to DNS servers of all interfaces, shouldn't host then send also TCP SYNs via all interfaces using all source addresses - and in case of SSL also try SSL over all interfaces?

So when application calls ConnectByName(FQDN), a burst of messages would be shot out of all interfaces, and the ConnectByName would then just pick the one that is up fastest?

Would that then solve pretty much most of the MIF problems and we could close and move along?-)

Best regards,

	Teemu

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Nov 2010 02:22:14 -0800

> The user can fallback to use single interface. 

How would the user know to fall back to a single interface?

> The latest draft now recommends using DNSSEC to validate responses.

I argued earlier that using DNSSEC without this draft was a better solution than this draft.   I still think that's the case.   The problem with recommendations of this sort is that they aren't enforceable, and aren't likely to be followed.  If, in order to get the behavior you want, you *have* to sign the zone, then that's more likely to happen.   So while I agree that a *requirement* to use DNSSEC here, if followed, would solve the problem, I don't think that the suggestion in the spec is going to help very much.

> Of course attacker can still *route* packets (and cause user to go to external side of www.corporation.com instead of internal?-)

This wouldn't work, because presumably they have different IP addresses.   If they have the same IP address, there's no need to have split DNS.

> In some scenarios the uplinks are always trusted (BBF). Sometimes you can administratively limit which interfaces to trust.

You are talking about the situation where the ISP controls the device that's doing the protocol then, right?   Traditionally the way we've done stuff like this is to put it in a cablelabs encapsulation; that way the people who need it for boxes they control have a clear specification, but it's not implemented on devices to which that specification doesn't apply (e.g., my iPad).

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 11:50:59 +0100

> How would the user know to fall back to a single interface?

How would the user know the network is instructing DNS queries should go over one interface or another at the first place?
 
> I argued earlier that using DNSSEC without this draft was a better
> solution than this draft.   I still think that's the case.   The

You also said:"DNSSEC doesn't remove split-horizon problems." So you say DNSSEC does not remove problems but is better solution than this. I have some hard time following the thinking and what the solution with DNSSEC would look like. Here I assume DNSSEC != send queries to all DNS servers.

> problem with recommendations of this sort is that they aren't
> enforceable, and aren't likely to be followed.  If, in order to get the
> behavior you want, you *have* to sign the zone, then that's more likely
> to happen.   So while I agree that a *requirement* to use DNSSEC here,
> if followed, would solve the problem, I don't think that the suggestion
> in the spec is going to help very much.

IETF cannot force implementation of anything that doesn't make sense in deployment at hand. Having DNSSEC MUST is pointless if there are imaginable real deployment scenarios where DNSSEC is just not needed - and where implementers can make the judgment call to not do DNSSEC if they know it is not needed. That way people who want security get it, but others can opt-out without violation MUST. But if you wish, we can have that MUST and the ignore in implementation phase:)

> You are talking about the situation where the ISP controls the device
> that's doing the protocol then, right?   Traditionally the way we've
> done stuff like this is to put it in a cablelabs encapsulation; that
> way the people who need it for boxes they control have a clear
> specification, but it's not implemented on devices to which that
> specification doesn't apply (e.g., my iPad).

This is the first time I hear that any DHCP option we specify gets implemented into iPad! Seriously, I'm sure you know people implement IETF specifications only when it makes sense for them (and sometimes don't implement even if it would have made sense, like we see in the level of IPv6 support in various places).

We are chartered to work on DHCP. We might be able to do this feature with things like ANDSF, 3GPP PCO IE, cablelabs, and so on, but is it really worthwhile to define same thing all over again in those places? Why not implement in DHCPv6 instead and then implement the DHCPv6 RFC on those devices where it applies. 

Best regards,

	Teemu

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Nov 2010 02:52:43 -0800

> Would that then solve pretty much most of the MIF problems and we could close and move along?-)

You say this as if it were a radical proposal, but in fact IMHO this is exactly the right place to start.   When you talk about making selections, like which interface to use or which DNS server to use, to me you are just optimizing around this fundamental solution.

For example, if you have an interface that's a lot more expensive than another interface, you might want to prefer the other interface as a starting position.   But if you're waiting 90 seconds before trying the other interface, or worse, not trying the other interface at all, I think you have a bad solution.   If the user wants you not to use the other interface, they should shut it down.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Nov 2010 02:59:21 -0800

> You also said:"DNSSEC doesn't remove split-horizon problems." So you say DNSSEC does not remove problems but is better solution than this. I have some hard time following the thinking and what the…

My proposal was to send the query to all DNS servers.   This way when one is signed and validates, and the other is not signed, you know which one to use.   If people choose not to use DNSSEC, then that's their problem.   When you query only one server, you are always running the risk that it will be the server that gives you the wrong answer.   Allowing an unauthenticated device to tell you not to query a particular server provides a way for an attacker to bypass DNSSEC.

> IETF cannot force implementation of anything that doesn't make sense in deployment at hand. Having DNSSEC MUST is pointless if there are imaginable real deployment scenarios where DNSSEC is just no…

You're making my point for me.

> We are chartered to work on DHCP. We might be able to do this feature with things like ANDSF, 3GPP PCO IE, cablelabs, and so on, but is it really worthwhile to define same thing all over again in t…

I've already explained to you at length why I think we should not do this.   I think at this point we're just repeating the same arguments.

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 12:08:41 +0100

> > So when application calls ConnectByName(FQDN), a burst of messages
> would be shot out of all interfaces, and the ConnectByName would then
> just pick the one that is up fastest?
> >
> You say this as if it were a radical proposal, but in fact IMHO this is
> exactly the right place to start.   When you talk about making
> selections, like which interface to use or which DNS server to use, to
> me you are just optimizing around this fundamental solution.

People here have worked in MIF related topics for several years. We are long past the starting point. For me your proposals sounds radical - like we would have gone to wrong direction with our optimizations - including the IESG that has approved our charter?

> For example, if you have an interface that's a lot more expensive than
> another interface, you might want to prefer the other interface as a
> starting position.   But if you're waiting 90 seconds before trying the

Right, this is exactly why with the proposed tools the network provider of the expensive interface can tell you that you should route only these packets and send only these DNS queries over this interface, but prefer sending other data somewhere else (low default route metric, low DNS default server metric).

But your proposals seem opposite to that, I see you proposing that we would send useless stuff over that expensive interface, or even interface that could be known to have limited connection. 

We need a compromise between very happy eyeballs and resources.

> other interface, or worse, not trying the other interface at all, I
> think you have a bad solution.   If the user wants you not to use the
> other interface, they should shut it down.

Considering DNS case, if the DNS server that knows about local namespaces is not responding, you are lost anyway. But for the case you were attacked and lured to ask from wrong server, there could be fast fallback to other servers. 

The attacks are probably not the common case, hence I don't see we should send DNS queries to all servers just to avoid rare attacks.

Best regards,

Teemu

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 12:11:18 +0100

> > We are chartered to work on DHCP. We might be able to do this feature
> with things like ANDSF, 3GPP PCO IE, cablelabs, and so on, but is it
> really worthwhile to define same thing all over again in those places?
> Why not implement in DHCPv6 instead and then implement the DHCPv6 RFC
> on those devices where it applies.
> 
> I've already explained to you at length why I think we should not do
> this.   I think at this point we're just repeating the same arguments.

Agree.

We need other opinions to find consensus for way forward.

	Teemu

---

From: <[email-masked]>
Date: Fri, 12 Nov 2010 01:53:17 +0100

FYI I'm working offline with Ted to come up with a revision of draft that hopefully addresses the concern, will let you know when something is available.

Meanwhile, any comments on these questions I had on the presentation:

1) Instead of multiple option instances change to use suboptions similar to DHCPv6 IA_RT

I think this is needed, but comments welcome if that is good idea or not (I personally couldn't get ISC DHCPv6 client work with multiple DHCPv6 option instances).

2) Install specific route for each DNS server address to ensure the DNS queries go out of right interface

This would increase reliability and I included it in -05. But comments welcome.

3) Should the DNS suffix list be compressed, like defined in RFC1035 section 4.1.4 or at draft-ietf-mip4-nemo-haaro-02 section 4.2 (dictionary based)? Savings would probably be quite small, but some still.

Do you think slightly added complexity is worthwhile to compress the suffix list a bit? Essentially repeating labels (.com, .www, etc) would be compressed.

Best regards,

Teemu

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Savolainen Teemu (Nokia-MS/Tampere)
> Sent: 11. marraskuuta 2010 19:11
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [mif] New revision of DNS server selection
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 11 Nov 2010 17:09:49 -0800

> I think this is needed, but comments welcome if that is good idea or not (I personally couldn't get ISC DHCPv6 client work with multiple DHCPv6 option instances).

I think this is a bug in the ISC client.   Multiple options are supposed to work.   I think the added complexity of an encapsulation is unnecessary.

> Do you think slightly added complexity is worthwhile to compress the suffix list a bit? Essentially repeating labels (.com, .www, etc) would be compressed.

Section 8 of RFC3315 is pretty definite about not doing this... :)

---

From: <[email-masked]>
Date: Fri, 12 Nov 2010 08:35:49 +0100

> > I think this is needed, but comments welcome if that is good idea or
> not (I personally couldn't get ISC DHCPv6 client work with multiple
> DHCPv6 option instances).
> 
> I think this is a bug in the ISC client.   Multiple options are
> supposed to work.   I think the added complexity of an encapsulation is
> unnecessary.

Ok, I could try with Dibbler as well (know that I came to meet the guy behind that:)

> > Do you think slightly added complexity is worthwhile to compress the
> suffix list a bit? Essentially repeating labels (.com, .www, etc) would
> be compressed.
> 

I know, but I thought it would be more just for RFC3315? But I'm fine on not doing any compression, but just wanted to raise it for discussions in case others see need for it.

Best regards