Fred and Washam,
I reacted too fast to previous remarks when I proposed to modify the accepted
IPv6 MTU in 6a44 draft.
If IPv6 packets longer than 1280 would be accepted by 6a44 servers, hosts could
receive them in fragmented IPv4 datagrams.
This would be contrary to the objective of simplicity
Dear Ted,
The version which passed the Softwire LC is
http://tools.ietf.org/html/draft-ietf-softwire-ds-lite-tunnel-option-04 which
included both name and IP address options.
After IESG review, 05 has been published but this version has significant
changes.
We are at least two service
Hi all,
Version -01 of the 6a44 draft has just been posted
(www.ietf.org/id/draft-despres-softwire-6a44-01.txt)
It includes correction of a substantial bug in Figure 3, an some clarifications.
Thanks to all those who helped to improve it.
Regards,
RD
Dear wg:
draft-ietf-softwire-ds-lite-tunnel-optionmailto:draft-ietf-softwire-ds-lite-tunnel-opt...@tools.ietf.org
has been reviewed by the IESG with input from the dhc wg. Their conclusion was
that having both an IP option and an FQDN option
to describe the tunnel-end-point was redundant. After
On Fri, Oct 08, 2010 at 05:36:48PM +0200, mohamed.boucad...@orange-ftgroup.com
wrote:
If there is a real issue with defining two DHCPv6 options (which I don't
see),
The problem of defining two options that convey the same configuration
point is a problem we call aliasing. Section 6 (Avoid
On Tue, Oct 12, 2010 at 07:26:10AM -0700, Ted Lemon wrote:
If you absolutely have to have the FQDN option, then get rid of the IP
address option.That eliminates the interoperability problem. In
any case, though, you need to issue a new draft.
As a B4 implementor, I reject the onerus
Folks,
VoIP protocols in MGCP and SIP have been supporting IP address and FQDN for a
long time. In VoIP deployment with FQDN use, the deployment always keeps a
local name resolver. So why not look carefully at the use cases operators are
presenting to advocate use of both FQDN and IP address
On Oct 12, 2010, at 4:58 PM, Hemant Singh (shemant) wrote:
I appreciate the feedback on DHCPv6 design style to not use two entities to
represent the same primitive but if DHCPv6 is such a stick in the mud, we
could go with some other control mechanism. After all several protocols use
FQDN
A general question. If 6rd could become an RFC in RFC 5969 with no
mention of FQDN for the BR, what is so special about DS-Lite and
deployments that a FQDN is needed by DS-Lite for the AFTR? I would
think the same FQDN issue would arise in 6rd as well... What did I miss?
Thanks,
Hemant
Hi Hemant,
As I know, since 6rd BRs are stateless, so you can configure an
anycast address for load balancing stuff.
Thanks,
washam
2010/10/13 Hemant Singh (shemant) shem...@cisco.com:
A general question. If 6rd could become an RFC in RFC 5969 with no
mention of FQDN for the BR, what is so
Dear Alain, all,
I strongly object to define only a single AFTR address option. As I mentioned
in previous e-mails, the FQDN name option is needed for some scenarios such as
load balancing. Having DHCP server acting as a load balancer is not an option
for us.
If the problem is only with the
11 matches
Mail list logo
