Subject: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration

From: Ted Lemon <[email-masked]>
Date: Tue, 12 Feb 2013 00:24:13 +0000

At the IETF meeting in Atlanta, we ended the session with a long discussion about how to solve the problem of configuring MAP-E and lw4over6 IPv4 stacks; several possibilities were presented, and we decided that we would write a draft summarizing these possibilities so that the working group could state a preference.

Time went on, and none of the people who volunteered actually did anything, so a couple of weeks ago Branimir Rajtar and Ian Farrer offered to write it up based on the notes from the last meeting.   They have done so, and submitted a -00 draft: https://datatracker.ietf.org/doc/draft-rajtar-dhc-v4configuration/

The purpose of this draft is to enumerate all the potential solutions to this problem, describe their pros and cons, and make a recommendation.   The current state of the draft is the recommendation that most people seemed to be leaning toward at the end of the meeting in Atlanta, but it's not binding; if during discussion the working group decides to recommend something else, the document will be updated to reflect that.

If you think the working group should in fact produce this document, please say so on the mailing list.   If you think we shouldn't produce such a document, please also say so.   If you have comments on the content of the document, please hold off on that until it's been adopted, or not adopted.   If it's not adopted, the comments are moot; if it is adopted, the job of the working group will be to finish it according to the input of working group participants, which is where your comments would come in.

We will evaluate consensus on February 25.

Thanks!

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 13 Feb 2013 12:17:57 +0100

Hello,
I do not support the adoption of this draft.
There are scenarios (like IPv6 with PPP) where DHCPv4 is not used at all, while DHCPv6 is required and already in place for IPv6 connectivity. Adding DHCPv4 would require changing the current architecture, while re-using DHCPv6 in my opinion appears a simpler approach.
Best regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Tuesday, February 12, 2013 1:24 AM
To: [email-masked] WG
Subject: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration

Thanks!

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

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 13 Feb 2013 12:24:24 +0100

Hi Ted,

think that to do a fair evaluation we'd need to go with a set of
requirements, which currently this document does not include. Eg It's
assumed that legacy DHCPv4 options are to be supported, but this is
definitely not a universal requirement and in fact a total non requirement
for several operators.

Thus it either needs to scope also set of requirements or those
requirements need to come in from Softwire. Without this, it's hard to see
how a pro/con analysis will prove to be useful.

Regards,
Woj.

On 12 February 2013 01:24, Ted Lemon <[email-masked]> wrote:

> At the IETF meeting in Atlanta, we ended the session with a long
> discussion about how to solve the problem of configuring MAP-E and lw4over6
> IPv4 stacks; several possibilities were presented, and we decided that we
> would write a draft summarizing these possibilities so that the working
> group could state a preference.
>
> Time went on, and none of the people who volunteered actually did
> anything, so a couple of weeks ago Branimir Rajtar and Ian Farrer offered
> to write it up based on the notes from the last meeting.   They have done
> so, and submitted a -00 draft:
> https://datatracker.ietf.org/doc/draft-rajtar-dhc-v4configuration/
>
> The purpose of this draft is to enumerate all the potential solutions to
> this problem, describe their pros and cons, and make a recommendation.
> The current state of the draft is the recommendation that most people
> seemed to be leaning toward at the end of the meeting in Atlanta, but it's
> not binding; if during discussion the working group decides to recommend
> something else, the document will be updated to reflect that.
>
> If you think the working group should in fact produce this document,
> please say so on the mailing list.   If you think we shouldn't produce such
> a document, please also say so.   If you have comments on the content of
> the document, please hold off on that until it's been adopted, or not
> adopted.   If it's not adopted, the comments are moot; if it is adopted,
> the job of the working group will be to finish it according to the input of
> working group participants, which is where your comments would come in.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Feb 2013 13:53:43 +0000

> There are scenarios (like IPv6 with PPP) where DHCPv4 is not used at all, while DHCPv6 is required and already in place for IPv6 connectivity. Adding DHCPv4 would require changing the current archi…

Using DHCPv6 is one of the three options described in the draft.   If you disagree with the current stated conclusions of the draft, that's a separate issue; the call for adoption is to address the question of whether the DHC working group should summarize the issues here and attempt to state a preferred solution.   Are you saying that the DHC working group should not make any decision at all about this?

---

From: Ole Troan <[email-masked]>
Date: Wed, 13 Feb 2013 14:58:38 +0100

Ted,

> Using DHCPv6 is one of the three options described in the draft.   If you disagree with the current stated conclusions of the draft, that's a separate issue; the call for adoption is to address the…

the draft is useful for discussion, although I disagree with the conclusion. I'm not sure if we ever want to publish this as an RFC, so I'm happy with keeping it as an individual contribution that we can use as basis for discussion and choices for the documents that we do publish.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Feb 2013 14:21:44 +0000

> the draft is useful for discussion, although I disagree with the conclusion. I'm not sure if we ever want to publish this as an RFC, so I'm happy with keeping it as an individual contribution that…

Okay, fair enough.   However, the purpose of doing the document _is_ to publish it as an RFC, so that the working group can have stated an opinion on how we would like to see this problem solved.   Right now we have a problem moving forward with any proposal because the working group's preferences on the question of how to configure IPv4 on an IPv6 network are not known or clearly stated, even though the working group has on several occasions communicated to other working groups, e.g. softwires, what we think the right thing is.

So until we adopt a draft like this and advance it to RFC, we are going to continue having to deal with this question over and over again.   This is why I want to see it adopted, and support adopting it.

---

From: Maglione Roberta <[email-masked]>
Date: Wed, 13 Feb 2013 15:37:37 +0100

Hi Ted,
  I understand that DHCPv6 is one of the options, but I disagree with current stated conclusions of the draft.
I agree with Ole that this draft could be useful for summarizing the discussion, but in my opinion the dhc working group should not work alone to solve this problem, softwire WG should be involved in this discussion.

Regards,
Roberta

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Feb 2013 14:47:49 +0000

> I agree with Ole that this draft could be useful for summarizing the discussion, but in my opinion the dhc working group should not work alone to solve this problem, softwire WG should be involved…

Softwire isn't chartered to define DHCP protocol extensions, so they can't do this work.   If softwire participants are interested in directing the discussion, they need to come to the DHC working group to do it.   We will in fact be discussing this document in the softwire meeting on Monday, but the work has to happen here, and has to be discussed here.

This document happens to be motivated by the softwires question at the moment, but the overall question of how to configure IPv4 hosts on an IPv6-only or dual-stack network is general—the working group has considered the question with respect to the work of a number of different working groups in the past.

If you think that DHCPv6 should be used to configure IPv4 hosts, you should support adopting this document and make your case in the working group.   The document is not cast in concrete, and as I said in the call for adoption, supporting adoption does not mean that you agree with the current conclusions of the document.

The current document simply concludes with what seemed to be the consensus at the end of the in-person meeting in Atlanta.   If that is not the real consensus of the working group, which is quite possible, that fact will emerge as a result of the working group working on the document.

---

From: Ole Troan <[email-masked]>
Date: Wed, 13 Feb 2013 15:58:14 +0100

Ted,

> If you think that DHCPv6 should be used to configure IPv4 hosts, you should support adopting this document and make your case in the working group.   The document is not cast in concrete, and as I…

the softwire solutions are largely concerned about configuring routers, not hosts.

> The current document simply concludes with what seemed to be the consensus at the end of the in-person meeting in Atlanta.   If that is not the real consensus of the working group, which is quite p…

that wasn't my impression when I left the meeting. unless you don't include MAP provisioning in that statement?
my recollection was that MAP used the combination of meta information to deduce its IPv4 address from the IPv6 address was perfectly fine in DHCPv6. provisioning a normal IPv4 address on top of a vanilla point to point tunnel I agree with is DHCPv4.
problem comes when you want to provision A+P. do you want to replicate very similar options between DHCPv6 and DHCPv4.
the unified CPE draft tried to come up with a single provisioning scheme. that draft uses DHCPv6 I thought.
(http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-02)

cheers,
Ole

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 13 Feb 2013 16:38:53 +0100

Ted,

I am in favour of the DHCP WG working with softwires to capture/define the
requirements and performing a subsequent DHCP analysis - so yes to adopting
that kind of draft. The scope of the proposed draft currently misses out on
that, or rather assumes an implicit set of requirements.

One of the points just expressed on this thread by Roberta is that for some
operators NOT having to use/deploy DHCPv4 is an actual requirement. For
others it may well be so. An analysis draft needs to capture these points
and their rationale, before the anlaysis.

Regards,
Woj.

On 13 February 2013 15:21, Ted Lemon <[email-masked]> wrote:

> > the draft is useful for discussion, although I disagree with the
> conclusion. I'm not sure if we ever want to publish this as an RFC, so I'm
> happy with keeping it as an individual contribution that we can use as
> basis for discussion and choices for the documents that we do publish.
>
> Okay, fair enough.   However, the purpose of doing the document _is_ to
> publish it as an RFC, so that the working group can have stated an opinion
> on how we would like to see this problem solved.   Right now we have a
> problem moving forward with any proposal because the working group's
> preferences on the question of how to configure IPv4 on an IPv6 network are
> not known or clearly stated, even though the working group has on several
> occasions communicated to other working groups, e.g. softwires, what we
> think the right thing is.
>
> So until we adopt a draft like this and advance it to RFC, we are going to
> continue having to deal with this question over and over again.   This is
> why I want to see it adopted, and support adopting it.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Feb 2013 16:29:41 +0000

On Feb 13, 2013, at 10:38 AM, Wojciech Dec <[email-masked]> wrote:
> One of the points just expressed on this thread by Roberta is that for some operators NOT having to use/deploy DHCPv4 is an actual requirement. For others it may well be so. An analysis draft needs to capture these points and their rationale, before the anlaysis.

Not having to deploy a protocol can't be a requirement.   It can certainly be a stated preference, and that preference can influence the determination of consensus, but it's a preference, not a requirement, because there is no technical reason for it.

---

From: Qi Sun <[email-masked]>
Date: Thu, 14 Feb 2013 00:31:40 +0800

Dear all,

I'm in favor of adopting the doc as a WG item. 

IMHO, it is the DHC WG's work to summarize the methods of configuring IPv4 resources. This doc will give explanations on why/why not IPv4  resources are configured this way over IPv6 network in transition period.

I also support the current conclusion.  It does not require modification of DHCPv6 protocol for transition by using DHCPv4o6 for IPv4 resources assignment. Once the Internet goes through the transition period, the modifications of DHCPv4 protocol will be abandoned with IPv4. No side effect on the development of IPv6.

Best Regards!

Qi Sun

---

From: Qi Sun <[email-masked]>
Date: Thu, 14 Feb 2013 00:48:10 +0800

Hi Ole,

> (http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-02)

[Qi] This is not what I read from the unified CPE draft. There is a DISCUSSION NOTE says that the customer side DHCP based provisioning method (DHCPv4/v6) will be updated to reflect the consensus from DHC WG. IMHO the draft-rajtar-* is doing the job.

Best Regards!

Qi Sun

---

From: <[email-masked]>
Date: Wed, 13 Feb 2013 18:31:45 +0100

Hi Ted,

I disagree. Not deploying a protocol is an operational requirement not a preference. There are other organizational issues to take into account (think about skills...). 

Cheers,
Med

>-----Message d'origine-----
>De : [email-masked] [mailto:[email-masked]] De 
>la part de Ted Lemon
>Envoyé : mercredi 13 février 2013 17:30
>À : Wojciech Dec
>Cc : [email-masked] WG; Capello Alessandro
>Objet : Re: [dhcwg] Call for adoption: draft-rajtar-dhc-v4configuration
>
>> One of the points just expressed on this thread by Roberta 
>is that for some operators NOT having to use/deploy DHCPv4 is 
>an actual requirement. For others it may well be so. An 
>analysis draft needs to capture these points and their 
>rationale, before the anlaysis.
>
>Not having to deploy a protocol can't be a requirement.   It 
>can certainly be a stated preference, and that preference can 
>influence the determination of consensus, but it's a 
>preference, not a requirement, because there is no technical 
>reason for it.
>

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 13 Feb 2013 19:17:58 +0100

On 13 February 2013 17:29, Ted Lemon <[email-masked]> wrote:

> > One of the points just expressed on this thread by Roberta is that for
> some operators NOT having to use/deploy DHCPv4 is an actual requirement.
> For others it may well be so. An analysis draft needs to capture these
> points and their rationale, before the anlaysis.
>
> Not having to deploy a protocol can't be a requirement.   It can certainly
> be a stated preference, and that preference can influence the determination
> of consensus, but it's a preference, not a requirement, because there is no
> technical reason for it.
>

It's not having to deploy infrastructure (at cost) to support a protocol to
solve a specific point problem that can be solved through other means. It's
thus directly linked to the operational bottom line of operators and one
would say that it's where technology requirments stem from.

regards,
Woj.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Feb 2013 18:25:27 +0000

On Feb 13, 2013, at 1:17 PM, Wojciech Dec <[email-masked]>
 wrote:
> It's not having to deploy infrastructure (at cost) to support a protocol to solve a specific point problem that can be solved through other means. It's thus directly linked to the operational bottom line of operators and one would say that it's where technology requirments stem from.

Right, this is a preference, not a requirement.   More to the point, all three solutions outlined in the draft require zero additional equipment other than the equipment that runs the DHCPv4 server.   It's hard to take this seriously as a prohibitive operational expense.

This objection was raised in the working group meeting in Atlanta, and I believe it's represented in the document; if not, please send suggested text to the authors.   The working group can weigh it.   Or not, if we decide not to do this work.

But do be aware that if we decide not to do this work, it doesn't mean, de facto, that softwires gets to make the decision.   It means that the dhc working group doesn't have consensus on what to do, and likely there can be no softwires DHCP solution at all.

---

From: Wojciech Dec <[email-masked]>
Date: Wed, 13 Feb 2013 20:00:03 +0100

On 13 February 2013 19:25, Ted Lemon <[email-masked]> wrote:

> > It's not having to deploy infrastructure (at cost) to support a protocol
> to solve a specific point problem that can be solved through other means.
> It's thus directly linked to the operational bottom line of operators and
> one would say that it's where technology requirments stem from.
>
> Right, this is a preference, not a requirement.   More to the point, all
> three solutions outlined in the draft require zero additional equipment
> other than the equipment that runs the DHCPv4 server.   It's hard to take
> this seriously as a prohibitive operational expense.
>

The server is not a major operational expense, the clients are, along with
all the bits needed along the path (relays) to make things work. Put in
another way, one would be very hard pressed to justify to a CTO of an
existing SP, why he has to go and invest and maintain in technolgy that he
can do without for the services the network is meant to offer.

Side note: DS-Lite is actually a example where no DHCPv4 is needed

>
> This objection was raised in the working group meeting in Atlanta, and I
> believe it's represented in the document; if not, please send suggested
> text to the authors.   The working group can weigh it.   Or not, if we
> decide not to do this work.
>

There are no requirements as far as I can tell in the document, other than
the implicit ones of the authors (not listed). That's why I think its scope
needs to be adjusted to cover both requirments and analysis. Before that
happens I do not think it should be adopted by the WG, as we'll be churning
for ever about the grounds for analysis.

>
> But do be aware that if we decide not to do this work, it doesn't mean, de
> facto, that softwires gets to make the decision.   It means that the dhc
> working group doesn't have consensus on what to do, and likely there can be
> no softwires DHCP solution at all.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 13 Feb 2013 20:27:42 +0000

On Feb 13, 2013, at 2:00 PM, Wojciech Dec <[email-masked]>
 wrote:
> The server is not a major operational expense, the clients are, along with all the bits needed along the path (relays) to make things work. Put in another way, one would be very hard pressed to justify to a CTO of an existing SP, why he has to go and invest and maintain in technolgy that he can do without for the services the network is meant to offer. 

For heaven's sake, if you're going to criticize the draft, please at least read it.   There are no relays needed—you already have an IPv6 address, so the packet can be unicast and routed directly to the DHCP server, in both alternatives that use a DHCPv4 server.   You have a device with a DHCPv6 client; adding a DHCPv4 client doesn't mean you have to buy another device.

> There are no requirements as far as I can tell in the document, other than the implicit ones of the authors (not listed). That's why I think its scope needs to be adjusted to cover both requirments and analysis. Before that happens I do not think it should be adopted by the WG, as we'll be churning for ever about the grounds for analysis.

Woj, the question in the document is, supposing we need to configure an IPv4 stack on an IPv6 only network, what is the DHC working group's advice as to how to do it?   This is a DHC document, not a softwire document.   What do you need to know about requirements beyond this, which is expressed in the draft?

---

From: Qi Sun <[email-masked]>
Date: Thu, 14 Feb 2013 11:21:10 +0800

Dear all,

Here is some analysis on this issue in draft-ietf-dhc-dhcpv4-over-ipv6-05:
http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-ipv6-05#appendix-A

IMO we can get some valuable input there. 

Best Regards!

Qi Sun

---

From: <[email-masked]>
Date: Thu, 14 Feb 2013 08:53:23 +0100

Hi Ole/Qi,

Qi's correct here. We were careful in writing the unified draft not to
state a DHCP version or transport throughout. it's concerned with how the
CPE should interpret the presence of configuration parameters so that it
can work out which softwire 'mode' to use.

Assuming that we get an outcome from this discussion in DHC, then
unified-cpe will be updated with the outcome.

Cheers,
Ian

On 13/02/2013 17:48, "Qi Sun" <[email-masked]> wrote:

>
>Hi Ole,
>
>> the unified CPE draft tried to come up with a single provisioning
>>scheme. that draft uses DHCPv6 I thought.
>[Qi] This is not what I read from the unified CPE draft. There is a
>DISCUSSION NOTE says that the customer side DHCP based provisioning
>method (DHCPv4/v6) will be updated to reflect the consensus from DHC WG.
>IMHO the draft-rajtar-* is doing the job.
>
>
>Best Regards!
>
>Qi Sun
>
>
>>>> I agree with Ole that this draft could be useful for summarizing the
>>>>discussion, but in my opinion the dhc working group should not work
>>>>alone to solve this problem, softwire WG should be involved in this
>>>>discussion.
>>> 
>>> Softwire isn't chartered to define DHCP protocol extensions, so they
>>>can't do this work.   If softwire participants are interested in
>>>directing the discussion, they need to come to the DHC working group to
>>>do it.   We will in fact be discussing this document in the softwire
>>>meeting on Monday, but the work has to happen here, and has to be
>>>discussed here.
>>> 
>>> This document happens to be motivated by the softwires question at the
>>>moment, but the overall question of how to configure IPv4 hosts on an
>>>IPv6-only or dual-stack network is general―the working group has
>>>considered the question with respect to the work of a number of
>>>different working groups in the past.
>>> 
>>> If you think that DHCPv6 should be used to configure IPv4 hosts, you
>>>should support adopting this document and make your case in the working
>>>group.   The document is not cast in concrete, and as I said in the
>>>call for adoption, supporting adoption does not mean that you agree
>>>with the current conclusions of the document.
>> 
>>> The current document simply concludes with what seemed to be the
>>>consensus at the end of the in-person meeting in Atlanta.   If that is
>>>not the real consensus of the working group, which is quite possible,
>>>that fact will emerge as a result of the working group working on the
>>>document.
>> 
>> that wasn't my impression when I left the meeting. unless you don't
>>include MAP provisioning in that statement?
>> my recollection was that MAP used the combination of meta information
>>to deduce its IPv4 address from the IPv6 address was perfectly fine in
>>DHCPv6. provisioning a normal IPv4 address on top of a vanilla point to
>>point tunnel I agree with is DHCPv4.
>> problem comes when you want to provision A+P. do you want to replicate
>>very similar options between DHCPv6 and DHCPv4.
>> the unified CPE draft tried to come up with a single provisioning
>>scheme. that draft uses DHCPv6 I thought.

---

From: Maglione Roberta <[email-masked]>
Date: Thu, 14 Feb 2013 09:20:59 +0100

Hi Ted,
  I think there is an additional architectural point to consider here: adding a DHCPv4 server just for this specific purpose, would introduce operational costs in terms of provisioning.
Provisioning is a sensitive issue for a service provider, trying to reduce the number of provisioning points is a key goal for a Service Provider and a trigger for developing optimized architecture. Seamless MPLS (draft-ietf-mpls-seamless-mpls) is one example of simplification of the operations achieved by reducing the provisioning points.
Introducing a DHCPv4 Server in addition to the existing/already required DHCPv6 Server, would require doubling the provisioning points,  having to split the provisioning for the same customer between two servers and having to deal with two sets of provisioning tools. This is definitely an operational issue for an operator.

Best regards,
Roberta

---

From: <[email-masked]>
Date: Thu, 14 Feb 2013 10:11:36 +0100

Hi Ted, all,

I agree with Woj here. 

The analysis is meaningless in the lack of clear and precise requirements. 
The analysis should not ignore which ongoing specification effort(s) is seeking for a position from dhc wg.
The analysis should not ignore to put this effort in the overall context of simplifying migration of networks to IPv6 (ideally IPv6-only mode).
The analysis should not ignore there are deployments which do not require anymore a dhcpv4 server (e.g.; DS-Lite).
The analysis should not ignore MAP is seen as an exist strategy from the DS-Lite model: it will be a no-starter for those operators to re-introduce DHCPv4.
The analysis should not ignore some fundamental design principle of some solutions such as MAP which assumes an algorithmic dependency between IPv4 and IPv6 addresses.
The analysis should not ignore the complications which may raise if both DHCPv6, DHCPv4, DHCPv4o6 relays are needed to cover legacy CPEs, IPv6-enabled CPEs and those services with a softwire-based IPv4 service continuity solution.
The analysis should not ignore that for some proposed solution, other means than DHCPvX can be used to learn an IPv4 address (and optionally a set of ports).

I really think this effort should be coordinated with softiwre wg.

Cheers,
Med

>Envoyé : mercredi 13 février 2013 21:28
>À : Wojciech Dec
>> The server is not a major operational expense, the clients 
>are, along with all the bits needed along the path (relays) to 
>make things work. Put in another way, one would be very hard 
>pressed to justify to a CTO of an existing SP, why he has to 
>go and invest and maintain in technolgy that he can do without 
>for the services the network is meant to offer. 
>
>For heaven's sake, if you're going to criticize the draft, 
>please at least read it.   There are no relays needed-you 
>already have an IPv6 address, so the packet can be unicast and 
>routed directly to the DHCP server, in both alternatives that 
>use a DHCPv4 server.   You have a device with a DHCPv6 client; 
>adding a DHCPv4 client doesn't mean you have to buy another device.
>
>> There are no requirements as far as I can tell in the 
>document, other than the implicit ones of the authors (not 
>listed). That's why I think its scope needs to be adjusted to 
>cover both requirments and analysis. Before that happens I do 
>not think it should be adopted by the WG, as we'll be churning 
>Woj, the question in the document is, supposing we need to 
>configure an IPv4 stack on an IPv6 only network, what is the 
>DHC working group's advice as to how to do it?   This is a DHC 
>document, not a softwire document.   What do you need to know 
>about requirements beyond this, which is expressed in the draft?
>

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 14 Feb 2013 10:52:11 +0100

> For heaven's sake, if you're going to criticize the draft, please at least read it.   There are no relays needed—you already have an IPv6 address, so the packet can be unicast and routed directly t…

Adding a new and yet more a custom DHCPv4 client to *anything* (even
existing devices) that don't have one, and arguably don't need one, is
a cost to an operator.

Re the relay and quoting the draft directly:
"On receipt at the tunnel concentrator (e.g. MAP Border Router or a
Lightweight 4over6 lwAFTR), the DHCPv4 message removed from the
softwire and forwarded to the DHCPv4 server in the same way as any
other IPv4 packet is handled."

This is clearly misinformed: AFTRs require special handling for
forwarding DHCPv4 traffic. Call it whatever you want, but I'll call it
a relay, since no AFTR will route back DHCPv4 traffic with a
destination address of 0.0.0.0 if not by acting as a DHCPv4 relay.

> Woj, the question in the document is, supposing we need to configure an IPv4 stack on an IPv6 only network, what is the DHC working group's advice as to how to do it?   This is a DHC document, not…

All I'm saying is that the requirements be laid out in the open along
with their rationale. Thankfully I seem to be not the only one.
I am puzzled by why you appear to be opposed to get the requirements
laid down before conducting an analysis of the solutions by the DHC
working group.

---

From: <[email-masked]>
Date: Thu, 14 Feb 2013 13:52:01 +0100

Hi Woj,

Comment in line.

Cheers,
Ian

On 14/02/2013 10:52, "Wojciech Dec" <[email-masked]> wrote:

>> > The server is not a major operational expense, the clients are, along
>>with all the bits needed along the path (relays) to make things work.
>>Put in another way, one would be very hard pressed to justify to a CTO
>>of an existing SP, why he has to go and invest and maintain in technolgy
>>that he can do without for the services the network is meant to offer.
>>
>> For heaven's sake, if you're going to criticize the draft, please at
>>least read it.   There are no relays needed‹you already have an IPv6
>>address, so the packet can be unicast and routed directly to the DHCP
>>server, in both alternatives that use a DHCPv4 server.   You have a
>>device with a DHCPv6 client; adding a DHCPv4 client doesn't mean you
>>have to buy another device.
>

It would have a destination of 0.0.0.0 if it was a DHCPDISCOVER message,
but it's a DHCPINFORM, which is a unicast and so can be handled the same
as any other v4 packet without a relay. That's why the draft states that a
mechanism to learn the unicast v4 address of the DHCPv4 server is
necessary (2 paragraphs below the text you've quoted above):

"For this approach to function, a mechanism for the DHCPv4 client to
   learn the IPv4 address of the DHCPv4 server is needed.  This could be
   done by defining a well-known IPv4 address for the DHCPv4 server,
   implementing a DHCPv4 relay function within the tunnel concentrator
   or other configuration methods."

>
>>
>>
>> > There are no requirements as far as I can tell in the document, other
>>than the implicit ones of the authors (not listed). That's why I think
>>its scope needs to be adjusted to cover both requirments and analysis.
>>Before that happens I do not think it should be adopted by the WG, as
>>we'll be churning for ever about the grounds for analysis.
>>
>> Woj, the question in the document is, supposing we need to configure an
>>IPv4 stack on an IPv6 only network, what is the DHC working group's
>>advice as to how to do it?   This is a DHC document, not a softwire
>>document.   What do you need to know about requirements beyond this,
>>which is expressed in the draft?
>
>

---

From: Wojciech Dec <[email-masked]>
Date: Thu, 14 Feb 2013 14:17:17 +0100

Hi Ian,

> necessary (2 paragraphs below the text you've quoted above):

But how does the response message (ACK or OFFER) from the server get
back to the client (that does not have an IPv4 address)?
>    or other configuration methods."

I suppose that this would be fulfilled by the DHCPv6 option for
specifying the IPv4 address of the DHCPv4 server. Correct?

Regards,
Woj.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 14 Feb 2013 17:44:00 +0000

> The analysis is meaningless in the lack of clear and precise requirements. 

The requirements are: we have a node that needs an IPv4 configuration on an IPv6 network.   In the context of using DHCP-based stateful configuration, how do we configure the IPv4 stack in the host?

Do you disagree with this?

For your reference, here's what the abstract of the document says:

   In order to provision end-user's hosts with the necessary IPv4
   configuration, a number of different mechanisms have been proposed.
   This memo discusses the benefits and drawbacks of each and recommend
   a single approach to use for the basis for future work.

Is there some aspect of the problem that is not described in the abstract?   Do you have proposed text?

---

From: Tina TSOU <[email-masked]>
Date: Thu, 14 Feb 2013 20:08:34 +0000

Dear all,
I think the WG should produce this document.
BTW, Happy Valentine to everyone.

Thank you,
Tina

> Sent: 2013年2月11日 16:24
> At the IETF meeting in Atlanta, we ended the session with a long discussion
> about how to solve the problem of configuring MAP-E and lw4over6 IPv4 stacks;
> several possibilities were presented, and we decided that we would write a
> draft summarizing these possibilities so that the working group could state
> a preference.
> 
> Time went on, and none of the people who volunteered actually did anything,
> so a couple of weeks ago Branimir Rajtar and Ian Farrer offered to write it
> up based on the notes from the last meeting.   They have done so, and
> submitted a -00 draft: https://datatracker.ietf.org/doc/draft-rajtar-dhc-
> v4configuration/
> 
> this problem, describe their pros and cons, and make a recommendation.   The
> current state of the draft is the recommendation that most people seemed to
> be leaning toward at the end of the meeting in Atlanta, but it's not binding;
> if during discussion the working group decides to recommend something else,
> the document will be updated to reflect that.
> 
> If you think the working group should in fact produce this document, please
> say so on the mailing list.   If you think we shouldn't produce such a
> document, please also say so.   If you have comments on the content of the
> document, please hold off on that until it's been adopted, or not adopted.
> If it's not adopted, the comments are moot; if it is adopted, the job of the
> working group will be to finish it according to the input of working group
> participants, which is where your comments would come in.
>

---

From: <[email-masked]>
Date: Fri, 15 Feb 2013 09:35:31 +0100

Hi Ted,

The question we have right now is closely related to softwire work. The IPv4 configuration (mainly an IPv4 address and optionally a set of port) should satisfy the following requirements:

* the solutions should accommodate deployment contexts where no dhcpv4 is deployed.
* the solution should accommodate IPv4 service continuity mechanisms which assumes a full dependency between an IPv4 address and IPv6 prefix.
* the solution should help in simplifying network operations when migrating to IPv6; in particular IPv4-only network services should not be required for operating an IPv6 network over which IPv4 service is offered.
* the solution should not optimize as much as possible required features to be activated in the network compared to a dual-stack model (e.g., this has a direct constraint on dhcp relay falvors to be embedded in the IP access node).

Note that all solutions discussed in softwire do not require extra IPv4 configuration (than the IPv4 address:[port set]). No IPv4 DNS server is needed for instance.

The provisioning discussion is also part of: http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-02. 

Cheers,
Med

>De : Ted Lemon [mailto:[email-masked]] 
>Envoyé : jeudi 14 février 2013 18:44
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : Wojciech Dec; [email-masked] WG; Capello Alessandro
>The requirements are: we have a node that needs an IPv4 
>configuration on an IPv6 network.   In the context of using 
>DHCP-based stateful configuration, how do we configure the 
>IPv4 stack in the host?
>

---

From: <[email-masked]>
Date: Fri, 15 Feb 2013 09:38:28 +0100

One correction inline.

>la part de [email-masked]
>Envoyé : vendredi 15 février 2013 09:36
>À : Ted Lemon
>The question we have right now is closely related to softwire 
>work. The IPv4 configuration (mainly an IPv4 address and 
>optionally a set of port) should satisfy the following requirements:
>
>* the solution should accommodate IPv4 service continuity 
>mechanisms which assumes a full dependency between an IPv4 
>address and IPv6 prefix.
>* the solution should help in simplifying network operations 
>when migrating to IPv6; in particular IPv4-only network 
>services should not be required for operating an IPv6 network 
>over which IPv4 service is offered.
>* the solution should not optimize as much as possible 

Med: s/should not/should.

>required features to be activated in the network compared to a 
>dual-stack model (e.g., this has a direct constraint on dhcp 
>relay falvors to be embedded in the IP access node).
>
>Note that all solutions discussed in softwire do not require 
>extra IPv4 configuration (than the IPv4 address:[port set]). 
>No IPv4 DNS server is needed for instance.
>
>The provisioning discussion is also part of: 
>http://tools.ietf.org/html/draft-bfmk-softwire-unified-cpe-02. 
>
>Cheers,
>Med
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 15 Feb 2013 14:26:33 +0000

There's been a lot of pushback on adopting this document; some of this I think is motivated by the fact that the document came with a conclusion, and people who disagree with this conclusion don't want to be seen as endorsing it by agreeing to adopt the document.   This is not the authors' fault—when we talked about this, I told them I thought it was okay to state a conclusion, which in retrospect was a mistake.

So I'd like to propose that we stop the call for adoption on this version of the document now, and that the authors reissue the document, without the recommendation section, and with the addition of Roberta's argument in favor of a DHCPv6-only solution, which I think captures the real issue best.

Would the authors be willing to do this?

---

From: <[email-masked]>
Date: Fri, 15 Feb 2013 17:18:10 +0100

Hi,

We've made those changes and posted a new version.

Cheers,
Ian

On 15/02/2013 15:26, "Ted Lemon" <[email-masked]> wrote:

>There's been a lot of pushback on adopting this document; some of this I
>think is motivated by the fact that the document came with a conclusion,
>and people who disagree with this conclusion don't want to be seen as
>endorsing it by agreeing to adopt the document.   This is not the
>authors' fault‹when we talked about this, I told them I thought it was
>okay to state a conclusion, which in retrospect was a mistake.
>
>So I'd like to propose that we stop the call for adoption on this version
>of the document now, and that the authors reissue the document, without
>the recommendation section, and with the addition of Roberta's argument
>in favor of a DHCPv6-only solution, which I think captures the real issue
>best.
>

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 22 Feb 2013 22:06:40 +0100

On 15.02.2013 15:26, Ted Lemon wrote:
> So I'd like to propose that we stop the call for adoption on this
> version of the document now, and that the authors reissue the
> document, without the recommendation section, and with the addition
> of Roberta's argument in favor of a DHCPv6-only solution, which I
> think captures the real issue best.
What is the plan with this work? I suppose it will be
presented/discussed in Orlando, updated version will be published and
second adoption call will be issued?

Ted said that this is adoption thread, not a technical comments thread,
but since the adoption call was cancelled, I hope it is ok to post my
comments on it.

I noted that -01 version does not include specific conclusion, merely a
note that this conclusion will emerge as a group consensus. This is a
step in right direction. My suggestion for the work forward would be to
decide what are the changes needed (if we want to be more specific about
requirements, what inside and what outside of scope, what the conclusion
should be) and then adopt it, not the other way around. At first, this
may be counter-intuitive, but there's a very good reason to do this in
that order. There was (still is, but it seems to be dying slowly and
being revived constantly) a draft about DHCPv6 routing configuration in
MIF wg. The draft was adopted a long time ago, but the group didn't have
consensus how it really should work. This is a hot controversial topic
with many participants having strong opinions, similar to what we have
here with draft-rajtar-dhc-v4configuration. If you attend MIF meetings,
you'll notice that discussion about this takes a significant amount of
time of every single MIF meeting, without much work going forward. I
would very much like to avoid similar case in DHC. This draft has
similar potential for endless pro and cons discussions as was
demonstrated many times in Softwires.

I agree with Woj's and Med's comments about a need to define what are
the requirements (or preferences as Ted calls some of them). Depending
on them, some pros/cons become very important or not important at all.

Ok, here are my comments specific to the text:

It would be helpful to add a stack description in sections 2.1, 2.2 and
2.3 (omething like DHCPv4/UDPv6/IPv6, DHCPv6/UDPv6/IPv6, and
DHCPv4/UDPv4/IPv4/IPv6).

Section 2.1: "The DHCPv4o6 server needs to be extended to support the new
functionality, such as storing the IPv6 address of DHCPv4o6 clients." Is
this really true? My undestanding is that the server needs to remember
IPv6 address of the source packet to respond to it, but once the
response is sent there is no need to store it further.

Section 2.2 is overly simplistic. DHCPv6 based provisioning aims to
provide only bare minimum to configure IPv4 stack, not the whole
multitude of options that DHCPv4 has.

Section 2.2 refers to I-D.mdt-softwire-map-dhcp-option, which is
obsolete. It was adopted as I-D.softwire-map-dhcp.

Section 2.3. Is there a draft available that proposes that architecture?

Section 3.1.1, bullet 1: Remove extra "be".

It should be mentioned that there's existing software that was proven to
work (other pro/con sections mention existence or lack of suitable
software).

Section 3.1.2, bullet 1: can you elaborate? CRA is the only new element
required. You can integrate it with client if you want to minimize
number of new elements.

Bullet 2 could possibly reference
draft-mrugalski-softwire-dhcpv4-over-v6-option-01.

Bullet 3 "DHCPv4 clients needs to be updated to implement the IPv6
encapsulation and decapsulation function." My understanding is that it
is not always true. CRA can be a
separate entity, you don't have to modify DHCPv4 client code.

Bullet 4 "The DHCPv4 server needs to be updated to implement new
DHCPv4o6 functionality.". I think that is not always true, as you can
deploy Transport Relay Agent, right?

You should add "requires DHCPv4 server to be deployed and maintained" to
cons.

Section 3.2.1 should mention that some solutions (MAP for sure. 4rd used
to, I'm not sure if it still does) reuse parts of the IPv6 configuration
(e.g. parts of PD) to provide IPv4 configuration.

Section 3.2.2, bullet 1 suggests that there are many DHCPv4 options that
would need to be ported, but in fact there are few (or even none) in
most cases.

I assume that bullet 2 discusses a new DHCPv6 options that are used to
configure IPv4 transition technology, e.g. MAP. It raises an interesting
point, which is considered
a strong argument against that solution. Here's an idea to consider that
could largely mitigate it. We could define a special range in DHCPv6
option space reserved for transition
technologies, similar to what we have in DHCPv4 option space for
reserved or private use. Any DHCPv6 options that would become useless
after IPv4 goes away, would be assigned from that range. Once a vendor
wants to go IPv6-only, it's just a matter of not supporting specific
range of options.

Bullet 3: I'm not sure where did you get the idea that DHCPv4 legacy
options would be ported to DHCPv6? Such a thing is unreasonable to say
the least. Can you point out
specific draft or comment that suggested that?

Section 3.3.1
"Uses the existing DHCPv4 and DHCPv6 architectures in order to provide
IPv4 configuration in an IPv6 only environment.". If you reword to
"requires..." instead of "uses...", it suddenly
may be considered a con in many deployments that do not have DHCPv4
deployed.

Section 3.3.2, bullet 4 mentions ietf-dhc-dhcpinform-clarify. This draft
is dead for over 2 years and David, its author, is unlikely to revive it.

You should add "requires DHCPv4 server to be deployed and maintained" to
cons.

You should add "no existing software available yet" to cons.

My personal observation is that this is not a completely solvable
problem and there won't be a single conclusion, like "use DHCPv4" or
"use DHCPv6" that would satisfy everyone (or at least a large majority).
I think the way forward here would be to do something similar as we did
in dhc-option-guidelines: define a set of guidelines, not "you must
always use X".

Hope that helps,
Tomek

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 24 Feb 2013 19:38:01 +0000

I think comments are always welcome :).

One concern I have (WG co-chair hat mostly off) with this whole area is that I don't really have a clear sense for what is required of the players - operator/service provider (in its network, for its devices) and what is required by the subscriber (client side) or OS provider.

While I understand that there may be situations where operators have no choice (because they have few IPv4 addresses), but I think it is important for us to understand what the tradeoffs are as there may be some operators that will continue to prefer providing IPv4.

Note that this isn't necessarily something that this particular draft has to provide, but it more of a general comment for all of the drafts in this space.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Friday, February 22, 2013 4:07 PM
To: [email-masked]
Subject: [dhcwg] Comments on draft-rajtar-dhc-v4configuration-01

On 15.02.2013 15:26, Ted Lemon wrote:
> document, without the recommendation section, and with the addition of 
> Roberta's argument in favor of a DHCPv6-only solution, which I think 
> captures the real issue best.
What is the plan with this work? I suppose it will be presented/discussed in Orlando, updated version will be published and second adoption call will be issued?

Ted said that this is adoption thread, not a technical comments thread, but since the adoption call was cancelled, I hope it is ok to post my comments on it.

I noted that -01 version does not include specific conclusion, merely a note that this conclusion will emerge as a group consensus. This is a step in right direction. My suggestion for the work forward would be to decide what are the changes needed (if we want to be more specific about requirements, what inside and what outside of scope, what the conclusion should be) and then adopt it, not the other way around. At first, this may be counter-intuitive, but there's a very good reason to do this in that order. There was (still is, but it seems to be dying slowly and being revived constantly) a draft about DHCPv6 routing configuration in MIF wg. The draft was adopted a long time ago, but the group didn't have consensus how it really should work. This is a hot controversial topic with many participants having strong opinions, similar to what we have here with draft-rajtar-dhc-v4configuration. If you attend MIF meetings, you'll notice that discussion about this takes a significant amount of time of every single MIF meeting, without much work going forward. I would very much like to avoid similar case in DHC. This draft has similar potential for endless pro and cons discussions as was demonstrated many times in Softwires.

I agree with Woj's and Med's comments about a need to define what are the requirements (or preferences as Ted calls some of them). Depending on them, some pros/cons become very important or not important at all.

It would be helpful to add a stack description in sections 2.1, 2.2 and
2.3 (omething like DHCPv4/UDPv6/IPv6, DHCPv6/UDPv6/IPv6, and DHCPv4/UDPv4/IPv4/IPv6).

Section 2.1: "The DHCPv4o6 server needs to be extended to support the new functionality, such as storing the IPv6 address of DHCPv4o6 clients." Is this really true? My undestanding is that the server needs to remember
IPv6 address of the source packet to respond to it, but once the response is sent there is no need to store it further.

Section 2.2 is overly simplistic. DHCPv6 based provisioning aims to provide only bare minimum to configure IPv4 stack, not the whole multitude of options that DHCPv4 has.

Section 2.2 refers to I-D.mdt-softwire-map-dhcp-option, which is obsolete. It was adopted as I-D.softwire-map-dhcp.

It should be mentioned that there's existing software that was proven to work (other pro/con sections mention existence or lack of suitable software).

Section 3.1.2, bullet 1: can you elaborate? CRA is the only new element required. You can integrate it with client if you want to minimize number of new elements.

Bullet 3 "DHCPv4 clients needs to be updated to implement the IPv6 encapsulation and decapsulation function." My understanding is that it is not always true. CRA can be a separate entity, you don't have to modify DHCPv4 client code.

Bullet 4 "The DHCPv4 server needs to be updated to implement new
DHCPv4o6 functionality.". I think that is not always true, as you can deploy Transport Relay Agent, right?

You should add "requires DHCPv4 server to be deployed and maintained" to cons.

Section 3.2.1 should mention that some solutions (MAP for sure. 4rd used to, I'm not sure if it still does) reuse parts of the IPv6 configuration (e.g. parts of PD) to provide IPv4 configuration.

Section 3.2.2, bullet 1 suggests that there are many DHCPv4 options that would need to be ported, but in fact there are few (or even none) in most cases.

I assume that bullet 2 discusses a new DHCPv6 options that are used to configure IPv4 transition technology, e.g. MAP. It raises an interesting point, which is considered a strong argument against that solution. Here's an idea to consider that could largely mitigate it. We could define a special range in DHCPv6 option space reserved for transition technologies, similar to what we have in DHCPv4 option space for reserved or private use. Any DHCPv6 options that would become useless after IPv4 goes away, would be assigned from that range. Once a vendor wants to go IPv6-only, it's just a matter of not supporting specific range of options.

Bullet 3: I'm not sure where did you get the idea that DHCPv4 legacy options would be ported to DHCPv6? Such a thing is unreasonable to say the least. Can you point out specific draft or comment that suggested that?

Section 3.3.1
"Uses the existing DHCPv4 and DHCPv6 architectures in order to provide
IPv4 configuration in an IPv6 only environment.". If you reword to "requires..." instead of "uses...", it suddenly may be considered a con in many deployments that do not have DHCPv4 deployed.

Section 3.3.2, bullet 4 mentions ietf-dhc-dhcpinform-clarify. This draft is dead for over 2 years and David, its author, is unlikely to revive it.

You should add "requires DHCPv4 server to be deployed and maintained" to cons.

My personal observation is that this is not a completely solvable problem and there won't be a single conclusion, like "use DHCPv4" or "use DHCPv6" that would satisfy everyone (or at least a large majority).
I think the way forward here would be to do something similar as we did in dhc-option-guidelines: define a set of guidelines, not "you must always use X".

Hope that helps,
Tomek

---

From: Branimir Rajtar <[email-masked]>
Date: Mon, 25 Feb 2013 11:00:50 +0000

Hi all,

First of all, I wanted to thank you for the comments that were given - I found them very useful. 

However, before I start going through them, I would like to get information from Bernie on how he wants to proceed with this draft. According to Ted Lemon's idea, we were going to get it approved and afterwards work on the details. In my opinion, it's a valid approach since we don't want to work on it and in the end it turns out that the WG doesn't have any need for it.

BR,
Branimir Rajtar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Sunday, February 24, 2013 8:38 PM
To: Tomek Mrugalski; [email-masked]
Subject: Re: [dhcwg] Comments on draft-rajtar-dhc-v4configuration-01

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Friday, February 22, 2013 4:07 PM
To: [email-masked]
Subject: [dhcwg] Comments on draft-rajtar-dhc-v4configuration-01

I noted that -01 version does not include specific conclusion, merely a note that this conclusion will emerge as a group consensus. This is a step in right direction. My suggestion for the work forward would be to decide what are the changes needed (if we want to be more specific about requirements, what inside and what outside of scope, what the conclusion should be) and then adopt it, not the other way around. At first, this may be counter-intuitive, but there's a very good reason to do this in that order. There was (still is, but it seems to be dying slowly and being revived constantly) a draft about DHCPv6 routing configuration in MIF wg. The draft was adopted a long time ago, but the group didn't have consensus how it really should work. This is a hot controversial topic with many participants having strong opinions, similar to what we have here with draft-rajtar-dhc-v4configuration. If you attend MIF meetings, you'll notice that discussion about this takes a significant
  amount of time of every single MIF meeting, without much work going forward. I would very much like to avoid similar case in DHC. This draft has similar potential for endless pro and cons discussions as was demonstrated many times in Softwires.

Section 3.3.1

Hope that helps,
Tomek

<HTML><P><FONT face=Arial color=#999999 size=1>

IZJAVA O ODRICANJU ODGOVORNOSTI: Sadržaj ove poruke i eventualno priloženih datoteka je povjerljiv i namijenjen je samo osobama ili subjektima koji su navedeni u adresi. Ukoliko ste primili ovu poruku greškom, molimo Vas, obavijestite pošiljatelja, a poruku i sve njene privitke odmah, bez čitanja, trajno uklonite s računala. Bilo kakvo prenošenje, kopiranje ili distribucija informacija sadržanih u poruci trećim osobama je zabranjeno i može biti zakonski kažnjivo. Sadržaj, stavovi i mišljenja izneseni u poruci su autorovi i ne predstavljaju nužno stavove HT - Hrvatskih telekomunikacija d.d. HT ne prihvaća nikakvu odgovornost za eventualnu štetu nastalu primitkom ove poruke i priloga sadržanih u poruci.

</FONT></P><P><FONT face=Arial color=#999999 size=1>

 DISCLAIMER:The contents of this email as well as any files attached to it are confidential and intended solely for individuals or entities which they are addressed to. If you have received this email message in error, please notify the sender and permanently remove the message and all attached files from the computer. Any disclosure, copying or distribution of all or a part of information contained herein to or by third parties is prohibited and may be unlawful. Please note that any views or opinions presented in this message are solely those of the author and do not necessarily represent the views and opinions of Croatian Telecom Inc. Croatian Telecom Inc. accepts no liability for any potential damage caused by this message and files attached to it.

</FONT></P></HTML>