Subject: [Tsvwg] SCTP : Dns resolving case:

From: "Asish Thomas Punnoose" <[email-masked]>
Date: Wed, 22 Aug 2001 00:29:56 -0700

Hello all,

I am new to this group and I wasn't sure whether this have beeen dicsussed;
but Jon says nothing of this sort is discussed and he suggests to air it on
the tsvwg mailing list. 

When a dns host name is insertd in the IP list at either endpoint; its the 
resposibility of the Rcv_Peer to resolve the address and update the IP list
 at its association point. Well the RFC takes about when to call the query 
based on the processing time, thats fine. 

Now my case is when a dns query lookup is used like say : nslookup 
hotmail.com we get a list of IP addresses which are stored in the dns 
database. 

#1 Are all these addressess of a single server with multiple interfaces wrt
SCTP?.	Are they all "eligible" multihoming address. 

#2 Could these addresses be of mirror sites.... (possibility or not?). I
think it could also have mirror sites and so what happens is that at the 
Rcv_Peer end point will have a list of IP addresses which are of multiple 
physical machines. 

Now the primary IP addresses of establish an association among themselves 
and the Rcv_Peer would start HBs along all other resolved IP address
fromthe  dns host name. 

If accidentally the other (physical) m/cs have sctp running; then it would 
act as a OOTB packet to that specific instance of SCTP running... in 
response (as per RFC section 8.4 rule 8) and ABORT would be send in 
response. 

Will this abort tear down the main association as the IP address of the
Abort sending m/c is a valid entry in the association list at Rcv_Peer. 

Could any please visualise the scenario and help on this. 

Thanks n rgds 
Asish Thomas 

Jon  wrote to me regarding this.... 
<JON>
>> JON >> One thought is "just don't do it". The peer advertising a
hostname in its init or init-ack, is I believe, claiming that the DNS
scenario you are describing does not exist (or cause problems). One is not
required to advertise by hostname. 
</JON>

_______________________________________________
tsvwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/tsvwg

---

From: Randall Stewart <[email-masked]>
Date: Wed, 22 Aug 2001 09:50:57 -0500

Asish:

A couple of comments...

1) If you look closely into RFC2960 you will note that specifically
   the host-name-address parameter does NOT specify using DNS or 
   any other resolution facility for that matter.

2) If you decide to use DNS for this feature (vs NIS, NIS2, /etc/hosts,
   or some other resolution method) you have to assure that a given
   hostname and its list of IP addresses IS all on the same host and
   not split across multiple hosts for load balancing. Otherwise you
   WILL get an ABORT back from one of the alternate addresses as you
   mention below. This is a configuration error and necessarily a
   problem with the protocol.

3) I very much doubt about the viability of this feature. In particular
   it is a very very difficult feature for any kernel implementation
   (where we hope most implementations of SCTP will be). This is because
   in order to implemente this in the kernel you have to do an UPcall
   to user land and then have this kernel point waiting on the user
   land to call back to DNS and get the resolution... very awkward and
   quite hard to do. I know we do NOT plan on implementing it for the
   BSD/KAME work we are doing.

4) So far no implementation at any of the bake-off's has supported
   this feature. Some have claimed that they could resolve such a
   name. But no implementation as yet generated the "host-name-address"
   parameter in a INIT or INIT-ACK.

Regards

R

Asish Thomas Punnoose wrote:
> -----------------------------------------------------------------------------------------------------------------------
> Information transmitted by this E-MAIL is proprietary to Wipro Limited and
> is intended for use only by the individual or entity to which it is
> addressed, and may contain information that is privileged, confidential or
> exempt from disclosure under applicable law. If you are not the intended
> recipient or it appears that this mail has been forwarded to you without
> proper authority, you are notified that any use or dissemination of this
> information in any manner is strictly prohibited. In such cases, please
> notify us immediately at mailto:[email-masked] and delete this mail
> from your records.
> ------------------------------------------------------------------------------------------------------------------------
> ----------------------------------------------------------------------------------------------------------------------
> Information transmitted by this E-MAIL is proprietary to Wipro Limited and
> is intended for use only by the individual or entity to which it is
> addressed, and may contain information that is privileged, confidential or
> exempt from disclosure under applicable law. If you are not the intended
> recipient or it appears that this mail has been forwarded to you without
> proper authority, you are notified that any use or dissemination of this
> information in any manner is strictly prohibited. In such cases, please
> notify us immediately at mailto:[email-masked] and delete this mail
> from your records.
> ----------------------------------------------------------------------------------------------------------------------
> 

-- 
Randall R. Stewart
[email-masked] 815-342-5222 (cell phone)