Re: FW: Evaluation of: draft-ietf-ipv6-node-requirements-07.txt
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: FW: Evaluation of: draft-ietf-ipv6-node-requirements-07.txt



> 
> > Set 3:
> > 
> > > One bigger issue, which may not be worth a Discuss, but 
> > > something that 
> > > IMHO should be discussed in some forum:
> > > 
> > >         All nodes that need to resolve names SHOULD implement stub-
> > >   resolver [RFC-1034] functionality, in RFC 1034 section 5.3.1 with
> > >   support for:
> > >                                                               
> > >     - AAAA type Resource Records [RFC-3596];
> > >     - reverse addressing in ip6.arpa using PTR records [RFC-3152];
> > >     - EDNS0 [RFC-2671] to allow for DNS packet sizes larger than 512
> > >       octets.
> > > 
> > > .. I'm operationally concerned about the last SHOULD.  As far as I 
> > > know, EDNS0 is not really implemented.  It does not seem to include a 
> > > SHOULD to something that hasn't seen practical, wide-spread deployment 
> > > already.  I'd recommend removing this or rewording it to a MAY.
> 
> 	Define "not really implemented".
> 
> 	RFC 2671 was published August 1999.
> 	Production servers w/ EDNS0 were release Jan 2000.
> 	The root servers have been EDNS aware for over a year if memory
> 	serves me.  There is still one holdout (B).
> 
> 	Even the load balancer cowboys are implementing EDNS0.
> 	Their server's may not understand MX/NS/SOA/AAAA but they
> 	do understand EDNS queries.
> 
> 	Over half the servers on the net currently talk EDNS based on
> 	the figures I have seen.
> 
> 	The majority of the problems come from servers that fail to
> 	implement RFC 1034 by dropping EDNS queries and firewalls that
> 	either reject additional records in queries or reject UDP answers
> 	bigger than 512 octets.  Retrying the query w/o EDNS on timeout
> 	addresses these.
> 
> 	The firewall vendors now have code that is EDNS aware.
> 	Most of the servers that dropped EDNS queries were load balancers.
> 	While we still have to win the battle to get them to understand
> 	AAAA.  They appear to have seen the light on EDNS.
> 
> 	I have no problem with a SHOULD for stub resolvers.  While most
> 	don't do it there is real unknowns in saying that they should
		          s/is real/is no real/
> 	do it.  The caching server they are using most probably is already
> 	making EDNS queries on their behalf.
> 
> 	Mark
> 
> > John
> > 
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> > 
> --
> Mark Andrews, Internet Software Consortium
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark.Andrews@isc.org

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.